This article is more than 1 year old
And now for something completely different: Python 3.12
Nobody expects more flexible string parsing
Python 3.12, the latest stable release of the Python programming language, was released on Monday, offering developers a handful of new capabilities and the removal of some cruft.
The revision arrives almost a year after the previous stable release, Python 3.11.
Python has recently been ranked the most popular, second most popular, or third most popular programming language, depending on whom you ask. Whatever the case, it's the lingua franca of data science and AI, and a common entry point into programming in academic settings.
The 3.12 release includes more accommodating f-strings, as was proposed in the Python Enhancement Proposal (PEP) 701.
An f-string, or formatted string literal, is a string literal prefixed by an 'f' – upper or lowercase – such that it can contain replacement fields within curly braces that get evaluated at run time. Most programming languages have something of the sort and with PEP 701, expression components within an f-string can be any valid Python expression. They can now handle multi-line expressions, comments, backslashes, and Unicode escape sequences.
PEP 695 offers an improved type parameter syntax that makes type variables easier to understand. It allows developers to declare type parameters "at a natural place within a class, function, or type alias declaration statement."
Python implements a Global Interpreter Lock, or GIL, that prevents multiple Python threads from executing at the same time. The GIL is set to become optional in the next version of Python 3.13 because it hinders concurrency – it's a safety bottleneck that blocks other threads.
In this release, Python has introduced a per-interpreter GIL with PEP 684. It allows the creation of sub-interpreters, which makes it easier to work with multiple CPU cores. Initially, this must be done with a C API, though a Python API is planned for 3.13. One of the potential use cases would be running sub-interpreters concurrently and accessing the shared state in a thread-safe C++ library.
- From browser brat to backend boss: Will WASM win the web wars?
- This profiler chatbot promises to help speed up your Python – we can believe it
- Microsoft teases Python scripting in Excel
- Sneaky Python package security fixes help no one – except miscreants
The latest Python update also arrives with support for PEP 669, a new API for profilers, debuggers, and other monitoring tools. PEP 669 is supposed to be "low-impact," so it can be implemented in code without significant overhead – debuggers and profilers have been known to slow code down by an order of magnitude.
"We have been following and are looking at incorporating some of the modifications made as part of PEP 669 to improve the performance of monitoring," University of Massachusetts Amherst computer science professor Emery Berger told The Register. Berger also noted that SlipCover – a near zero-overhead Python code coverage tool that he and graduate student Juan Altmayer Pizzorno developed – served as inspiration for PEP 669.
Berger, Pizzorno, and another graduate student, Sam Stern, also developed a Python profiler called Scalene. And Berger said he and his students are exploring how they can add some of the Python 3.12 changes into their existing projects.
"We plan to use [PEP 669] to further reduce the overhead of Scalene's line-level tracking of memory usage, especially for some pathological cases," said Berger. "No surprise, given SlipCover was used as justification for the PEP, we are looking at using it to streamline and future-proof the implementation of SlipCover."
Other Python 3.12 improvements include PEP 688, which makes the buffer protocol – a way to access the underlying memory of an object – accessible via a Python API instead of just a C API, and PEP 709, which adds a compiler optimization called inlining to list, dictionary, and set comprehensions for improved performance.
Also, there are some type hint improvements, for those who prefer to be explicit about Python data types (PEP 692 and PEP 698). And error messages have been improved.
Finally, beyond the various module enhancements, a slew of older features were removed after several years in deprecation purgatory. All the details are available in the online documentation. ®