4 ms·

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?

by causal 2y ago

instig007 2y ago
Have a rubust CI and tests, and deploy as early as you can.
- kstrauser 2y ago
  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.
  - odie5533 2y ago
    This is the way.
zenonu 2y ago
I'm constrained by libraries with guaranteed version compatibility. Unless you're operating in NIH universe, I bet you are as well.
user070223 2y ago
When should you upgrade to Python 3.13? https://pythonspeed.com/articles/upgrade-python-3.13/ https://pythonspeed.com/articles/upgrade-python-3.13/ Python libraries support https://pyreadiness.org/3.13/ https://pyreadiness.org/3.13/
oebs 2y ago
We follow this rule (about two dozen services with in total ~100k loc of Python): By default, use the version 1 release below the latest. I.e. we currently run 3.11 and will now schedule work to upgrade to 3.12, which is expected to be more or less trivial for most services. The rationale is that some of the (direct and transitive) dependencies will take a while to be compatible with the latest release. And waiting roughly a year is both fast enough to not get too much behind, and slow enough to expect that most dependencies have caught up with the latest release.
- jnwatson 2y ago
  Yeah some deprecated C API stuff just got removed, so it might take me, a package maintainer, to catch up.
yn6n767m76m 2y ago
Scream into a pillow because even PHP manages to have less breaking releases. Python is a dumpster fire that no one wants to admit or have an honest conversation about. If python 2 is still around my advice is don't upgrade unless you have a clear reason for the new features.
ilc 2y ago
n-1 is the rule I follow. So if asked today I'd look at 3.12.
- rantingdemon 2y ago
  So simple, yet so effective. Old Systems Admins like me have been following this simple rule for decades. It's the easiest way at scale.
HelloNurse 2y ago
Wait until they are actually released rather than RC3. What's the point of posting prematurely?
zahlman 2y ago
>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.
BiteCode_dev 2y ago
I follow this: https://www.bitecode.dev/p/installing-python-the-bare-minimum https://www.bitecode.dev/p/installing-python-the-bare-minimu... Which is mostly latest_major - 1, adjusted to production constraints, obviously. And play with latest for fun. I stopped using latest even for non serious projects, the ecosystem really needs time to catch up.
dagw 2y ago
Rule 1 is wait until there are built wheels for that version of python for all the libraries that you need. In most cases that can take a month or two, depending on exactly what libraries you use and how obscure they are.

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?

by causal 2y 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?

instig007 2y ago

Have a rubust CI and tests, and deploy as early as you can.

kstrauser 2y ago
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.
- odie5533 2y ago
  This is the way.

zenonu 2y ago

I'm constrained by libraries with guaranteed version compatibility. Unless you're operating in NIH universe, I bet you are as well.

user070223 2y ago

When should you upgrade to Python 3.13? https://pythonspeed.com/articles/upgrade-python-3.13/ https://pythonspeed.com/articles/upgrade-python-3.13/ Python libraries support https://pyreadiness.org/3.13/ https://pyreadiness.org/3.13/

oebs 2y ago

We follow this rule (about two dozen services with in total ~100k loc of Python): By default, use the version 1 release below the latest. I.e. we currently run 3.11 and will now schedule work to upgrade to 3.12, which is expected to be more or less trivial for most services. The rationale is that some of the (direct and transitive) dependencies will take a while to be compatible with the latest release. And waiting roughly a year is both fast enough to not get too much behind, and slow enough to expect that most dependencies have caught up with the latest release.

jnwatson 2y ago
Yeah some deprecated C API stuff just got removed, so it might take me, a package maintainer, to catch up.

yn6n767m76m 2y ago

Scream into a pillow because even PHP manages to have less breaking releases. Python is a dumpster fire that no one wants to admit or have an honest conversation about. If python 2 is still around my advice is don't upgrade unless you have a clear reason for the new features.

ilc 2y ago

n-1 is the rule I follow. So if asked today I'd look at 3.12.

rantingdemon 2y ago
So simple, yet so effective. Old Systems Admins like me have been following this simple rule for decades. It's the easiest way at scale.

HelloNurse 2y ago

Wait until they are actually released rather than RC3. What's the point of posting prematurely?

zahlman 2y ago

>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.

BiteCode_dev 2y ago

I follow this: https://www.bitecode.dev/p/installing-python-the-bare-minimum https://www.bitecode.dev/p/installing-python-the-bare-minimu... Which is mostly latest_major - 1, adjusted to production constraints, obviously. And play with latest for fun. I stopped using latest even for non serious projects, the ecosystem really needs time to catch up.

dagw 2y ago

Rule 1 is wait until there are built wheels for that version of python for all the libraries that you need. In most cases that can take a month or two, depending on exactly what libraries you use and how obscure they are.