3 ms·

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

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.

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.