Here's What's New in Python 3.12 (geeky-gadgets.com) 39
Monday will see the stable release of Python 3.12. Here's an article summarizing what the new version will include:
- enhanced error messages
— performance upgrades
- the introduction of Immortal objects and sub interpreters
- changes to F strings
- modifications related to types and type annotations
- the removal of certain modules
- improvements in type implementations
Modules from the standard library are now suggested as part of the error messages, making it easier for developers to troubleshoot and resolve issues...
Another significant addition in Python 3.12 is the introduction of sub interpreters. Each sub interpreter has its own Global Interpreter Lock, enabling Python to better utilize multiple CPU cores. This feature can significantly enhance the performance of Python programs, especially those that are designed to take advantage of multi-core processors...
The pathlib module now has a walk method, allowing for the exploration of directory trees. This new feature can make it easier for developers to work with file systems in their Python programs. Python 3.12 also supports the ability to monitor calls, returns, lines, exceptions, and other events using instrumentation. This feature can be very useful for debugging and performance tuning.
- enhanced error messages
— performance upgrades
- the introduction of Immortal objects and sub interpreters
- changes to F strings
- modifications related to types and type annotations
- the removal of certain modules
- improvements in type implementations
Modules from the standard library are now suggested as part of the error messages, making it easier for developers to troubleshoot and resolve issues...
Another significant addition in Python 3.12 is the introduction of sub interpreters. Each sub interpreter has its own Global Interpreter Lock, enabling Python to better utilize multiple CPU cores. This feature can significantly enhance the performance of Python programs, especially those that are designed to take advantage of multi-core processors...
The pathlib module now has a walk method, allowing for the exploration of directory trees. This new feature can make it easier for developers to work with file systems in their Python programs. Python 3.12 also supports the ability to monitor calls, returns, lines, exceptions, and other events using instrumentation. This feature can be very useful for debugging and performance tuning.
What it will include... (Score:4, Informative)
It will include incompatibilities and code breakages.
Millions of working programs will stop working.
Re: What it will include... (Score:2)
The dont use IT, until you updated your Code...
Re: (Score:1)
...update your code to something other than Python
Re: (Score:3)
Oh, come on. Basic wasn't that bad.
Re: (Score:2)
It definitely was not!
BASIC has been much maligned but it was really not that bad. Pretty good actually. Some of it stems from very ancient BASIC with only goto, and one of Dijkstra's let's say pithy quotes. Other's because people love to shit on stuff to feel superior.
BASIC certainly was not glacially slow like python (which is a side effect of the dynamism in the language: everything has to bee looked up over multiple levels sometimes at runtime), a lot of effort was put into making it run pretty fast and
Re: (Score:1)
Here is an idea.. and I love the fact that it will get buried in sub-comments on Slashdot with viewership of 20 people.
Instead of making the developer annotate everything and type cast, why not make the runtime analyze the type and box it in?
You may be thinking 'but its never been done before, shits hard yo!' and yeah, thats why you get paid the big bucks to be a developer.
Python's performance should start off as a dynamic dumb language 'I donno if this is a string or an integer, we'll find out!' but over s
Re: (Score:2)
Not a bad idea: I'm moderately sure that's how the good JavaScript engines work.
There's a few things in python which make it quite a bit harder than JavaScript. There's pypy which is an alternative implementation which is much faster, not much less popular.
Re: (Score:2)
MY code?
What about all that third party code? Am I supposed to fix it to be able to work tomorrow?
Re: (Score:2)
I feel your pain. I consider dependency management as one of the most important, and yet most neglected, tasks of a senior developer, which, supposedly, is what I am.
I consider it unlikely, though certainly possible, that the handful of deprecations/removals would break significant amounts of code.
But hopefully there are unit/regression/integration tests in place that you could simply re-run, and these should hopefully catch the majority of problems that this or any Python upgrades might cause or trigger?
I
Re: (Score:2)
Cue millions of fanboys screaming in our ears to update because SECURITY or whatever.
Me, I'm getting a bit sick of forced innovation. Laugh all you want, but I'm stuck maintaining some old PHP code, and it absolutely sucks how many times I have to rewrite tons of shit every time a new version is released. Is it really necessary to change how the each() construct works? Really?
Re: (Score:1)
Yes like changing the format of the print statement for no good reason. God knows that change was super necessary, it kept people on 2.7 for like a decade.
Re: What it will include... (Score:2)
This was actually an easy fix, using 2to3 for example.
For me the really annoying one was changing the meaning of division on integers, from an integer division to a real division. There is no automatic deterministic and correct way to translate the relevant code, since there is no static way to know if a division is on integers or on reals.
Re: What it will include... (Score:5, Insightful)
For me, the *really* annoying ones are the incompatibilities introduced in 3.x.
While the 2.x->3.x was chock full of annoyances, at least the world recognized it and there was a lot of understanding and accommodation around the situation.
However, every 3.x they break *some* compatibility with 3.x-1 code, but there isn't a *whole* lot of accommodation. Funny enough, looking it up, Python 3.9 ended 'active support' the same *day* that RedHat Enterprise Linux 9 shipped, with the default python interpreter version being 3.9. I know RH signs up to support it longer term than upstream, but knowing that 3.9 code *might* depend on behaviors that are broken in 3.10 but upstream considers 3.9 to be dead
Contrast to say C, where the core toolchain aims to be able to build 25 year old code with enough options. Sure, some dependencies may not have been maintained to work, but the compiler and libc and certain other 'core' components. Meanwhile 'core' python may not bother supporting code that is 18 months old.
Re: (Score:3)
Yes like changing the format of the print statement for no good reason. God knows that change was super necessary, it kept people on 2.7 for like a decade.
Also:
What's new? The removal of certain modules
This count as something new indeed I guess...
Anyway, if those modules were certain, why did they remove them? /s
Re: (Score:2)
Print was broken from the start and needed to be replaced. How Guido managed to get it wrong after multiple attempts is a mystery.
Re: What it will include... (Score:3)
Enhanced error messages (Score:1)
Why can't these languages have more helpful error messages? Like hey you forgot to end that line with a semicolon or your whitespace is fucked up. Instead of undeclared instance of blah blah blah.
Re: (Score:1)
Because the compiler has no way of whether you're just plain idiot or merely forgot the semicolon.
Re: (Score:3)
Why can't these languages have more helpful error messages? Like hey you forgot to end that line with a semicolon or your whitespace is fucked up. Instead of undeclared instance of blah blah blah.
Perhaps what you want is PL/C [wikipedia.org], a teaching-oriented version of the PL/I language used in one of my CS classes way back in the day:
The PL/C compiler, which implemented almost all of the large PL/I language, had the unusual capability of never failing to compile a program, through the use of extensive automatic correction of many syntax errors and by converting any remaining syntax errors to output statements.
However, I vaguely remember that the auto-correct feature was usually more annoying than useful because it almost never correctly guessed what I meant. Maybe it would work better with today's AI models driving it.
changes to F strings (Score:2)
They should make it incompatible with 3.11 (Score:3)
Oh the fun we had. And are still having.
Re: (Score:2)
The first item on the agenda of the 3.12 committee: What we need to break in 3.11
Re: (Score:2)
When you get down to it, ever 3.x breaks compatibly with *some* code that ran with 3.x-1 (though at least usually with warning, but you are largely SOL on even the warnings if you don't try *every* single release and skip the generation with deprecation warnings). Some things are graced with longer deprecation warnings (imp has been warning since 3.4, for example).
Re: (Score:2)
To some extent that is true of all languages. Admittedly Python breaks more often in my experience than most.
You want a solid discipline around dependency management, automated testing, and code coverage, so you can find out sooner rather than later if your code OR dependencies have broken, and thus hopefully have time to fix it.
And as I mentioned before, if you don't have that type of process completely in place, now is a great time to start and/or improve it.
It sucks that we have to, especially on a time
Re: (Score:2)
While it's good to have coverage and automating testing, the volume of times the testing triggers manual intervention to revisit code that you really didn't have time to revisit is onerous. I have various projects and the C code that doesn't have any new requirements basically happily sits and never needs massaging. If they were GUI applications for Linux, then I'd probably be annoyed by the GUI libraries being fickle, but at least the parts I deal with are exceedingly careful about backwards compatibilit
Re: (Score:2)
I fully agree that it's a pain, and in fact it is the limiting factor preventing more widespread adoption where I work. Also why I generally do not create large Python code bases. It's great for my scripting needs at home, and I wouldn't be averse to creating smallish Web apps with it. But nothing huge.
I really, really want to like Python, but the continuous-painful-upgrade cycle is real, and, while full-time Pythoners may know ways to mitigate the pain, a LOT of people who write Python code do so only o
sub interpreters (Score:4, Insightful)
"Each sub interpreter has its own Global Interpreter Lock, enabling Python to better utilize multiple CPU cores."
*better utilize* maybe, but not WELL utilize. As Python development says:
"Note that objects are not shared between interpreters since they are tied to the interpreter in which they were created."
So you can get two GILs but they won't share address space. Really nailing that thread-level concurrency! Wonder if they know what threads actually are?
Good job, Python, keep demonstrating that you will never offer acceptable performance.
Re:sub interpreters (Score:5, Informative)
Good job, Python, keep demonstrating that you will never offer acceptable performance.
For starters, it's an interpreted language, and the official interpreter doesn't have a JIT compiler as far as I can tell. The poor multithreading support just adds insult to injury.
It's funny: I write a lot of little programs in C++, and people will say things to me like, "you should have used Python! You could have used X library. You would have finished writing the code 10x or 100x faster." Move over, Fred Brooks. There is a silver bullet, and it's Python.
In response to one such person, I emailed a Monte Carlo routine I wrote in multithreaded C++, noting its performance, and asking if they can do that in Python, lol. I still think static typing and compiling to machine code are good things regardless...
Re: sub interpreters (Score:2)
Great programs can be written in almost any language, and just because one person is more productive with Python does not mean everyone will be more productive with python. I like using Python in place of bash scripts. I like Python for lots of simple apps. I've done a little data science with Python. Like any interpreted language, Python will call out to fast C libraries to handle the number crunching. Python will never be as fast as MKL BLAS at matrix operations. It is not supposed to be. It doesn't need
Re: (Score:3)
Sure, Python doesn't need to be fast if its use is limited to areas that don't require speed. That's fine.
I question whether there are such things as great programs.
I still receive the advice that for essentially anything targeted at a laptop or desktop (vs. embedded microcontroller), coding in Python will make the development cycle 10x to 100x as fast as C++. I think that's BS.
Additionally, using interpreted languages still strikes me as somewhat of a waste of computer time, although I suppose we have sup
Re: (Score:2)
Most of them are written in C. Most of the rest are written in FORTRAN.
Re: (Score:2)
So you can get two GILs but they won't share address space. Really nailing that thread-level concurrency!
it's obviously a hack, python wasn't designed with multi or parallel processing in mind, and as a result is highly coupled to the global context, most python code from standard libraries to user modules isn't reentrant, meaning at this point that python as a specification probably won't ever be. you could easily include semantics for thread locked code sections, semaphores, threads, shared memory, whatever, but there is already a too huge mountain of code that will not play nice with that. it's too late, a
Re: sub interpreters (Score:2)
Python, JS... (Score:1)
If your code needs C-level performance, write the critical parts in C/C++, this used to be the mantra. I don't like where the new development is going to address what problems that are the direct consequence of fundamental design choices. Then if you write computationally intense code in Python that's your faul
Re: (Score:2)
At home (almost exclusively Linux), Python is my go-to language for scripting.
Work is mostly a Microsoft shop.
I'd like to use Python here too, and do, to an extent.
But it's still a pain to get past the "works on my machine" issue when sharing code with other devs. We all know some Python but it is not our daily driver. I'm sure we'd be able to figure out venvs and setuptools and such if we were primarily a Python shop, but we're not.
In spite of Powershell's many flaws, it's still easier for us to share Po
Not enough detail (Score:3, Informative)
https://docs.python.org/3.12/w... [python.org]