6 ms·

> For whatever reason (maybe post 2to3 PTSD), Python community seems not extremely eager to jump on latest versions of Python Well, you'd think after the 2 to

> For whatever reason (maybe post 2to3 PTSD), Python community seems not extremely eager to jump on latest versions of Python Well, you'd think after the 2 to 3 debacle, python might take backwards compatibility more seriously, but they don't. Follow semver, and stop breaking things on 3.x. If it's deprecated in 3.x, don't remove it until 4.

brianwawok 2y ago
Meh. I’d rather we move faster and make the world better even if we have to update code a bit more. Never that hard.
- KronisLV 2y ago
  I’ve seen woefully outdated enterprise projects that are unlikely to ever be updated to new runtimes (think Java 8 to anything newer, alongside the limitations JDK version support brings), due to nobody having the manpower to port up to a million lines over while hoping for it to be bug for bug compatible. Moving fast is really nice when you can get paid for shipping and have the project either be retired or someone else’s problem in a decade.
- KaiserPro 2y ago
  Updates cost money, or time. Most places don't have the resources to keep updating everything for little benefit. (just look at node its terrible to support. )
throwaway127482 2y ago
What have they broken on 3.x? Genuine question as I haven't followed python's development super closely
- skeledrew 2y ago
  Some seldom used standard modules have been deprecated and later removed. Like recently I revisited a project I initially made using v3.6, but it broke on v3.13 due to an indirect dependency no longer present in the stdlib. It was a simple fix though as a quick search identified the issue and pointed to the removed module in a package on PyPI.
  - hamandcheese 2y ago
    Yeah, it's nothing crazy, but it makes upgrades a lot more unpredictable. It's harder to communicate to management why the 3.x update took a day and the 3.y upgrade took a whole quarter. It's harder to upgrade services in a central way with any amount of leverage, and generally requires more coordination overhead, and moving more carefully. Compare with, say, golang, where it's pretty much a non-issue. My experience with Ruby was a lot better too, until Ruby 3, but hey, that was a major version bump!
  - fulafel 2y ago
    Python 3.6 is from 2016 and 3.13 is from 2024. Similar things happen on most platforms on this timescale, eg on the Java side[1], you'd be going from Java 8 to Java 23. Clojure is pretty good even on that timescale though. [1] See eg https://stackoverflow.com/a/50445603 https://stackoverflow.com/a/50445603 up until 2021
    - skeledrew 2y ago
      Yep it's totally understandable, and OK by me as these changes are documented in the release docs and the fix a pip install away.
    - trallnag 2y ago
      I often see people recommending Python as a replacement for Bash scripts (utilizing common Unix tools like grep and awk). I'm pretty sure a script from 2016 will still be working fine now.
      - swiftcoder 2y ago
        > I'm pretty sure a bash script from 2016 will still be working fine now. In some environments, yes. A bunch of platforms have started using bash-compatible (but not actually bash) shells like fish to help with startup performance. Apple has upgraded from a truly ancient version of bash to a somewhat-modern one in that time (and then gone all-in on zsh instead). Things change on the scale of a decade.
- SOLAR_FIELDS 2y ago
  Removal of setuptools in 3.12 broke a ton of legacy builds. Basically created a wall of forced package upgrades for a huge amount of packages in PypI where end users have to bump a bunch of stuff if they want to migrate from < 3.12 to 3.12+
  - Flimm 2y ago
    setuptools was never part of Python's standard library. I think you're thinking of distutils which was removed from Python in the 3.12 release. You can easily access distutils again by installing a package from PyPI.
    - SOLAR_FIELDS 2y ago
      You are right, it was distutils. Good call out. Not sure why I thought of setuptools.
      - JamesonNetworks 2y ago
        This comment thread is a microcosm of the problems with python packaging :D I appreciate the work the ecosystem does on it and everyone is doing their best, but its still a hard problem that doesn't feel solved
        feznyng 2y ago
        Check out uv if you haven’t.
- CamouflagedKiwi 2y ago
  One that I ran into at previous job: 3.10 removes the ability to implicit cast floats to ints in a bunch of places. That was very much a breaking change for a bunch of code out there.
  - pletnes 2y ago
    Never heard of. Do you have any concrete examples? Would be good to know about for me in 2025.
  - brianwawok 2y ago
    Comparing ints and floats sounds like a pretty high nono in basically any language ever. Why more python projects should use MyPy and not freely switch float to int to decimal. They aren’t the same thing.
- Kwpolska 2y ago
  They have been removing features every release for the past few years. Code that was working fine on 3.10 may break on 3.13 just because it was using a feature they didn't like.
- formerly_proven 2y ago
  Every release removes / breaks stuff in the standard library and has been for a while. That's because prior to ~3.2 or so, deprecations were basically never followed up on, but now deprecation means it's going to be removed. E.g. Python 3.12 has deprecated datetime.utcnow(). So it will probably be removed in Python 3.14 or 3.15. For all intents and purposes, "Python 3" is now the brand and "Python 3.x" releases are major, breaking releases.
- physicsguy 2y ago
  The async initial implementation changed in such a way as to break existing code
skeledrew 2y ago
I don't think there's even a plan for a v4. The fallout from 2 to 3 was that bad. So to keep improvements going takes deprecating something several versions before removing, and research is done to find how popular that particular thing is to determine its candidacy for removal. Thus it's best practice to pin all dependencies, and read the release notes before doing a version update.
- Numerlor 2y ago
  Yeah it'd be better if the name was understood as python 3 instead of just python to avoid mixing in semver
Uptrenda 2y ago
My thoughts exactly. Python was supposed to be this ultra-portable thing. But... I am finding myself having to write patches to get my software to work on different Python versions. People who have Python 3 installed can be on many different versions. The thing is, depending on the version, quite often bug fixes included in later versions aren't in older versions. So if you want to make your code work -- got to get the patches in manually, monkey patch broken code, and do it that way. Then there's the seemingly random deprecation of standard library modules / other breaking changes. I take python version support seriously because if people install your packages you'll be outsourcing all of the above crap to the user. They might not even know how to 'upgrade' python. Or end up on the wrong version. If your package doesn't work when they install it they'll just move on to something else. Python is a total shit show for packaging.
- trollbridge 2y ago
  I use Poetry and pin the Python version. Ugly, but it works.
  - holdenweb 2y ago
    Given the many ways of creating virtual environments it's becoming more usual for a program's installation to create a specialist virtual environment just to support that application (pre-commit is. good example of this technique). Perhaps that'a a way ahead?
    - pjc50 2y ago
      This is almost mandatory if you want to ship something which might be considered "standalone" on Python.
      - trollbridge 2y ago
        It's quite ugly, and I try to make sure I write modules that can be built to a standard wheel and installed that way. (Poetry makes this fairly easy, incidentally.) Doing development on the projects without a specialised build environment, though, is almost hopeless. You either have to manually install a bunch of stuff (e.g. I use ruff, used to use ruff and black, used pre-commit, and a few other things), and then there's the non-Python things that need to be installed (like specific fonts in my case). At this point I just impose Poetry as basically a requirement for development. The program does build and function in a non-Poetry environment which is what I use for production.
sgarland 2y ago
Python doesn’t follow semver [0], it follows a general major.minor.bugfix, but with an extremely liberal definition of minor (“less earth-shattering,” as they describe it). PEP387 requires that introduced incompatibilities have a “large benefit to breakage ratio,” and that any deprecations last a minimum of two years. FWIW, Kubernetes has a similar approach. Breaking changes occur all the time with “minor” version updates. [0]: https://docs.python.org/3/faq/general.html https://docs.python.org/3/faq/general.html [1]: https://peps.python.org/pep-0387/ https://peps.python.org/pep-0387/
ensignavenger 2y ago
Why should Python follow semver? There are plenty of successful projects that don't use semver. If you feel so strongly about them making the change, than make a case for it.

brianwawok 2y ago

Meh. I’d rather we move faster and make the world better even if we have to update code a bit more. Never that hard.

KronisLV 2y ago
I’ve seen woefully outdated enterprise projects that are unlikely to ever be updated to new runtimes (think Java 8 to anything newer, alongside the limitations JDK version support brings), due to nobody having the manpower to port up to a million lines over while hoping for it to be bug for bug compatible. Moving fast is really nice when you can get paid for shipping and have the project either be retired or someone else’s problem in a decade.
KaiserPro 2y ago
Updates cost money, or time. Most places don't have the resources to keep updating everything for little benefit. (just look at node its terrible to support. )

throwaway127482 2y ago

What have they broken on 3.x? Genuine question as I haven't followed python's development super closely

skeledrew 2y ago
Some seldom used standard modules have been deprecated and later removed. Like recently I revisited a project I initially made using v3.6, but it broke on v3.13 due to an indirect dependency no longer present in the stdlib. It was a simple fix though as a quick search identified the issue and pointed to the removed module in a package on PyPI.
- hamandcheese 2y ago
  Yeah, it's nothing crazy, but it makes upgrades a lot more unpredictable. It's harder to communicate to management why the 3.x update took a day and the 3.y upgrade took a whole quarter. It's harder to upgrade services in a central way with any amount of leverage, and generally requires more coordination overhead, and moving more carefully. Compare with, say, golang, where it's pretty much a non-issue. My experience with Ruby was a lot better too, until Ruby 3, but hey, that was a major version bump!
- fulafel 2y ago
  Python 3.6 is from 2016 and 3.13 is from 2024. Similar things happen on most platforms on this timescale, eg on the Java side[1], you'd be going from Java 8 to Java 23. Clojure is pretty good even on that timescale though. [1] See eg https://stackoverflow.com/a/50445603 https://stackoverflow.com/a/50445603 up until 2021
  - skeledrew 2y ago
    Yep it's totally understandable, and OK by me as these changes are documented in the release docs and the fix a pip install away.
  - trallnag 2y ago
    I often see people recommending Python as a replacement for Bash scripts (utilizing common Unix tools like grep and awk). I'm pretty sure a script from 2016 will still be working fine now.
    - swiftcoder 2y ago
      > I'm pretty sure a bash script from 2016 will still be working fine now. In some environments, yes. A bunch of platforms have started using bash-compatible (but not actually bash) shells like fish to help with startup performance. Apple has upgraded from a truly ancient version of bash to a somewhat-modern one in that time (and then gone all-in on zsh instead). Things change on the scale of a decade.
SOLAR_FIELDS 2y ago
Removal of setuptools in 3.12 broke a ton of legacy builds. Basically created a wall of forced package upgrades for a huge amount of packages in PypI where end users have to bump a bunch of stuff if they want to migrate from < 3.12 to 3.12+
- Flimm 2y ago
  setuptools was never part of Python's standard library. I think you're thinking of distutils which was removed from Python in the 3.12 release. You can easily access distutils again by installing a package from PyPI.
  - SOLAR_FIELDS 2y ago
    You are right, it was distutils. Good call out. Not sure why I thought of setuptools.
    - JamesonNetworks 2y ago
      This comment thread is a microcosm of the problems with python packaging :D I appreciate the work the ecosystem does on it and everyone is doing their best, but its still a hard problem that doesn't feel solved
      - feznyng 2y ago
        Check out uv if you haven’t.
CamouflagedKiwi 2y ago
One that I ran into at previous job: 3.10 removes the ability to implicit cast floats to ints in a bunch of places. That was very much a breaking change for a bunch of code out there.
- pletnes 2y ago
  Never heard of. Do you have any concrete examples? Would be good to know about for me in 2025.
- brianwawok 2y ago
  Comparing ints and floats sounds like a pretty high nono in basically any language ever. Why more python projects should use MyPy and not freely switch float to int to decimal. They aren’t the same thing.
Kwpolska 2y ago
They have been removing features every release for the past few years. Code that was working fine on 3.10 may break on 3.13 just because it was using a feature they didn't like.
formerly_proven 2y ago
Every release removes / breaks stuff in the standard library and has been for a while. That's because prior to ~3.2 or so, deprecations were basically never followed up on, but now deprecation means it's going to be removed. E.g. Python 3.12 has deprecated datetime.utcnow(). So it will probably be removed in Python 3.14 or 3.15. For all intents and purposes, "Python 3" is now the brand and "Python 3.x" releases are major, breaking releases.
physicsguy 2y ago
The async initial implementation changed in such a way as to break existing code

skeledrew 2y ago

I don't think there's even a plan for a v4. The fallout from 2 to 3 was that bad. So to keep improvements going takes deprecating something several versions before removing, and research is done to find how popular that particular thing is to determine its candidacy for removal. Thus it's best practice to pin all dependencies, and read the release notes before doing a version update.

Numerlor 2y ago
Yeah it'd be better if the name was understood as python 3 instead of just python to avoid mixing in semver

Uptrenda 2y ago

My thoughts exactly. Python was supposed to be this ultra-portable thing. But... I am finding myself having to write patches to get my software to work on different Python versions. People who have Python 3 installed can be on many different versions. The thing is, depending on the version, quite often bug fixes included in later versions aren't in older versions. So if you want to make your code work -- got to get the patches in manually, monkey patch broken code, and do it that way. Then there's the seemingly random deprecation of standard library modules / other breaking changes. I take python version support seriously because if people install your packages you'll be outsourcing all of the above crap to the user. They might not even know how to 'upgrade' python. Or end up on the wrong version. If your package doesn't work when they install it they'll just move on to something else. Python is a total shit show for packaging.

trollbridge 2y ago
I use Poetry and pin the Python version. Ugly, but it works.
- holdenweb 2y ago
  Given the many ways of creating virtual environments it's becoming more usual for a program's installation to create a specialist virtual environment just to support that application (pre-commit is. good example of this technique). Perhaps that'a a way ahead?
  - pjc50 2y ago
    This is almost mandatory if you want to ship something which might be considered "standalone" on Python.
    - trollbridge 2y ago
      It's quite ugly, and I try to make sure I write modules that can be built to a standard wheel and installed that way. (Poetry makes this fairly easy, incidentally.) Doing development on the projects without a specialised build environment, though, is almost hopeless. You either have to manually install a bunch of stuff (e.g. I use ruff, used to use ruff and black, used pre-commit, and a few other things), and then there's the non-Python things that need to be installed (like specific fonts in my case). At this point I just impose Poetry as basically a requirement for development. The program does build and function in a non-Poetry environment which is what I use for production.

sgarland 2y ago

Python doesn’t follow semver [0], it follows a general major.minor.bugfix, but with an extremely liberal definition of minor (“less earth-shattering,” as they describe it). PEP387 requires that introduced incompatibilities have a “large benefit to breakage ratio,” and that any deprecations last a minimum of two years. FWIW, Kubernetes has a similar approach. Breaking changes occur all the time with “minor” version updates. [0]: https://docs.python.org/3/faq/general.html https://docs.python.org/3/faq/general.html [1]: https://peps.python.org/pep-0387/ https://peps.python.org/pep-0387/

ensignavenger 2y ago

Why should Python follow semver? There are plenty of successful projects that don't use semver. If you feel so strongly about them making the change, than make a case for it.