With the 3.13 TypeIs[0] and the 3.10 TypeGuard[1], we can achieve some of Rust's power (such as the 'if let' pattern) without runtime guarantees.
This is a win for the DX, but this is not yet widely used. For example, "TypeGuard[" appears in only 8k Python files on GitHub.[2]
[0] -- https://docs.python.org/3.13/library/typing.html#typing.Type...
[1] -- https://docs.python.org/3.13/library/typing.html#typing.Type...
[2] -- https://github.com/search?q=%22TypeGuard%5B%22+path%3A*.py&t...
Python version from 3.10 have had a very annoying bug with the SSLContext (something related only to glibc) where there are memory leaks when opening new connections to new hosts and eventually causes any service (dockerized in my case) to crash due to OOM. Can still see that the issues have not been resolved in this release which basically makes it very difficult to deploy any production grade service difficult.
> Free-threaded execution allows for full utilization of the available processing power by running threads in parallel on available CPU cores. While not all software will benefit from this automatically, programs designed with threading in mind will run faster on multi-core hardware.
Would be nice to see performance improvements for libraries like FastAPI, NetworkX etc in future.
What I've been surprised about is the number of python packages that require specific python versions(e.g., works on 3.10, but not 3.11. Package versioning is already touchy enough without the language itself causing it in minor upgrades.
And will python 3.14 be named pi-thon 3.14. I will see myself out.
Good to get advanced notice, if I read all the way down, that they will silently completely change the behavior of multiprocessing in 3.14 (only on Unix/Linux, in case other people wonder what’s going on), which is going to break a bunch of programs I work with.
I really like using Python, but I can’t keep using it when they just keep breaking things like this. Most people don’t read all the release notes.
Still in prerelease (RC3), no? At least at time of writing
And Azure Functions still doesn't support Python 3.12, released more than a year ago!
Any rule of thumb when it comes to adopting Python releases? Is it usually best to wait for the first patch version before using in production?
I appreciate the effort to leave out the "And now for something completely different" section (on https://www.python.org/downloads/release/python-3130/) after the previous drama.
When I'm in a docker container using the Python 3 version that comes with Debian - is there an easy way to swap it out for this version so I can test how my software behaves under 3.13?
looking forward to the GraalVM version
I has officially been released: https://blog.python.org/2024/10/python-3130-final-released.h...
I still see Python 3.12.7 being the latest one, with 3.13 delayed because of the GC perf regression. The link, for me, points to the 3.13 RC.
Am I seeing a cached version and you see 3.13 ? Cause I can't see it on the homage page download link either.
[flagged]
Python versions 3.11, 3.12 and now 3.13 have contained far fewer additions to the language than earlier 3.x versions. Instead the newest releases have been focusing on implementation improvements - and in 3.13, the new REPL, experimental JIT & GIL-free options all sound great!
The language itself is (more than) complex enough already - I hope this focus on implementation quality continues.