And Azure Functions still doesn't support Python 3.12, released more than a year ago!
We have switched to exclusively using Docker Images in Lambda on AWS cause their runtime team constantly breaks things and is behind with a bunch of releases.
Python 3.13.0 Is Released
31–40 of 135 posts
Re: Python 3.13.0 Is Released
#32Any 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?
Wait until they are actually released rather than RC3. What's the point of posting prematurely?
Re: Python 3.13.0 Is Released
#33Any 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?
>Any rule of thumb when it comes to adopting Python releases?
No, because it varies widely depending on your use case and your motivations.
>Is it usually best to wait for the first patch version before using in production?
This makes it sound like you're primarily worried about a situation where you host an application and you're worried about Python itself breaking. On the one hand, historically Python has been pretty good about this sort of thing. The bugfixes in patches are usually quite minor, throughout the life cycle of a minor version (despite how many of them there are these days - a lot of that is just because of how big the standard library is). 3.13 has already been through alpha, beta and multiple RCs - they know what they're doing by now. The much greater concern is your dependencies - they aren't likely to have tested on pre-release versions of 3.13, and if they have any non-Python components then either you or they will have to rebuild everything and pray for no major hiccups. And, of course, that applies transitively.
On the other hand, unless you're on 3.8 (dropping out of support), you might not have any good reason to update at all yet. The new no-GIL stuff seems a lot more exciting for new development (since anyone for whom the GIL caused a bottleneck before, will have already developed an acceptable workaround), and I haven't heard a lot about other performance improvements - certainly that hasn't been talked up as much as it was for 3.11 and 3.12. There are a lot of quality-of-implementation improvements this time around, but (at least from what I've paid attention to so far, at least) they seem more oriented towards onboarding newer programmers.
And again, it will be completely different if that isn't your situation. Hobbyists writing new code will have a completely different set of considerations; so will people who primarily maintain mature libraries (for whom "using in production" is someone else's problem); etc.
Re: Python 3.13.0 Is Released
#34Python 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.
Removing GIL only increases complexity.
For the runtime, but not the language
Re: Python 3.13.0 Is Released
#35Earlier quoted context omitted.
This[0] is the Docker Python using Debian Bookworm, so as soon as 3.13.0 (not the release candidate I've linked to) is released, there will be an image. Otherwise, there's always the excellent `pyenv` to use, including this person's docker-pyenv project [1] [0] https://hub.docker.com/layers/library/python/3.13.0rc3-slim-... [1] https://github.com/tzenderman/docker-pyenv?tab=readme-ov-fil...
Hmm.. I think this is a misunderstanding. What I meant is: While I am already inside a container running Debian, can I ... 1: ./myscript.py 2: some_magic_command 3: ./myscript.py So 1 runs it under 3.11 (which came with Debian) and 2 runs it under 3.13. I don't need to preserve 3.11. some_magic_command can wrack havoc in the container as much as it wants. As soon as I exit it, it will be gone anyhow. The in a sense,…
The magic command in other settings would be pyenv. It lets you have as many different Python versions installed as you wish.
Pro tip: outside Docker, don’t ever use the OS’s own Python if you can avoid it.
Re: Python 3.13.0 Is Released
#36Python 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.
I've love to see a revamp of the import system. It is a continuous source of pain points when I write Python. Circular imports all over unless I structure my program explicitly with this in mind. Using python path hacks with `sys` etc to go up a directory too.
Re: Python 3.13.0 Is Released
#37Any 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?
Have a rubust CI and tests, and deploy as early as you can.
Yup. At my last gig, upgrading to a new version meant setting the Docker tag to the new one and running `make test`. If that passed, we were 99% certain it was safe for prod. The other 1% was covered by running in pre-prod for a couple days.
Re: Python 3.13.0 Is Released
#38Python 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.
> The language itself is (more than) complex enough already - I hope this focus on implementation quality continues. As do I.
Agreed. I still haven’t really started using the ‘match’ statement and structural pattern matching (which I would love to use) since I still have to support Python 3.8 and 3.9. I was getting tired of thinking, “gee this new feature will be nice to use in 4 years, if I remember to…”
Re: Python 3.13.0 Is Released
#39Earlier quoted context omitted.
This[0] is the Docker Python using Debian Bookworm, so as soon as 3.13.0 (not the release candidate I've linked to) is released, there will be an image. Otherwise, there's always the excellent `pyenv` to use, including this person's docker-pyenv project [1] [0] https://hub.docker.com/layers/library/python/3.13.0rc3-slim-... [1] https://github.com/tzenderman/docker-pyenv?tab=readme-ov-fil...
Hmm.. I think this is a misunderstanding. What I meant is: While I am already inside a container running Debian, can I ... 1: ./myscript.py 2: some_magic_command 3: ./myscript.py So 1 runs it under 3.11 (which came with Debian) and 2 runs it under 3.13. I don't need to preserve 3.11. some_magic_command can wrack havoc in the container as much as it wants. As soon as I exit it, it will be gone anyhow. The in a sense,…
You can use pyenv to create multiple virtual environments with different Python versions, so you'd run your script with (eg) venv311/bin/python and venv313/bin/python
Re: Python 3.13.0 Is Released
#40Earlier quoted context omitted.
Hmm.. I think this is a misunderstanding. What I meant is: While I am already inside a container running Debian, can I ... 1: ./myscript.py 2: some_magic_command 3: ./myscript.py So 1 runs it under 3.11 (which came with Debian) and 2 runs it under 3.13. I don't need to preserve 3.11. some_magic_command can wrack havoc in the container as much as it wants. As soon as I exit it, it will be gone anyhow. The in a sense,…
The magic command in other settings would be pyenv. It lets you have as many different Python versions installed as you wish. Pro tip: outside Docker, don’t ever use the OS’s own Python if you can avoid it.
> don’t ever use the OS’s own Python if you can avoid it.
This includes Homebrew's Python installation, which will update by itself and break things.