5 ms·

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.
      - jkaplowitz 2y ago
        And yet, if the script is written to POSIX sh standards and has the #!/bin/sh shebang line, none of that breaks. Yes, of course, things do change incompatibly in a decade, probably including some of the nonstandard platform-specific commands called by the script regardless of which dialect of shell. But people who use a nonstandard shell dialect - however common it might be at the time of writing - should be prepared for that shell to become uncommon, absent by default, installed at a different path, incompatibly changed, or otherwise unusable a decade later to an extent that people writing to the standard do not.
    - nuancebydefault 2y ago
      The bash side will still work but the tools called by bash won't. Same goes for python/packages.
    - Too 2y ago
      Assuming the script even worked fine in the first place. Usually quite unlikely.
    - fulafel 2y ago
      They break more often than Python scripts, from reasons unrelated to bash versions, though.
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

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.
    - jkaplowitz 2y ago
      And yet, if the script is written to POSIX sh standards and has the #!/bin/sh shebang line, none of that breaks. Yes, of course, things do change incompatibly in a decade, probably including some of the nonstandard platform-specific commands called by the script regardless of which dialect of shell. But people who use a nonstandard shell dialect - however common it might be at the time of writing - should be prepared for that shell to become uncommon, absent by default, installed at a different path, incompatibly changed, or otherwise unusable a decade later to an extent that people writing to the standard do not.
  - nuancebydefault 2y ago
    The bash side will still work but the tools called by bash won't. Same goes for python/packages.
  - Too 2y ago
    Assuming the script even worked fine in the first place. Usually quite unlikely.
  - fulafel 2y ago
    They break more often than Python scripts, from reasons unrelated to bash versions, though.

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