8 ms·

I'm normally joyful when a modern language (say, julia) decides to break backward compatibility to improve the language on a fundamental level. This is mostly b

I'm normally joyful when a modern language (say, julia) decides to break backward compatibility to improve the language on a fundamental level. This is mostly because I'm not too vested in it. For languages where I have 10+ years of work behind, it's the exact opposite, and where I see the c/c++ model of not breaking backward compatibility a much saner choice. Python in particular is an extremely bittersweet pill to swallow. The amount of small and large breakage I had ever since I started to use it for production work (v2.6 and onward) has been relentless. Small and large breakages requiring constant retooling and reworking. Minor release? Yeah, still breaks just as much as a major one. pyenv doesn't help when you dependencies need to be updated, and the updates do not support the lower versions you wanted to use anyway. Containerizing everything is a not a solution for a project is expected to be supported for years so the real way forward is to fix it, again, and again, and again. My experience is that every 6 months there _will_ be work just to fix bitrotting. A one year old python project will hardly even run unless it's using the stdlib only. By comparison, I never experienced such churn with perl.

forgotmypw17 4y ago
This is the top reason I chose Perl for my project. Literally every time I try to use someone else's Python code from GitHub I run into this crap. I wanted my project to be easy to install and run, so I chose Perl.
- jjgreen 4y ago
  I have had Perl scripts which I've not used for 15 years, run them expecting to need to fix something, but nothing needed ...
  - somat 4y ago
    The really nice part of sticking with python2 is that it is now a a stable interface. just like perl 5. only half joking.
    - forgotmypw17 4y ago
      I would consider it, except it is no longer being installed most places, since it is "deprecated".
- wakeupcall 4y ago
  It's a real shame, since this is a project management issue. You'd expect python to be a stable language given its age. I expected that to be the case at 2.7. Then at 3.1. At 3.12 it's still not the case. It's reasonable to expect this is not going to change.
  - forgotmypw17 4y ago
    I think with backwards compatibility it's "fool me once". In order to make the most of Lindy Effect, I avoid any dependencies with less than 20 years of backwards compatibility. For some that means a subset of features. For some like Python it means any python scripts must be optional and have Perl duplicates.
  - chaxor 4y ago
    It's gotten far, FAR worse since Guido stopped having as much guidance. The increase in mandatory updates at regular intervals is a recipe for disaster in most cases, as it is in python. Also, to pile on top of the stdlib problems - it's probably clear to most everyone at this point - but NVIDIA and Google (tensorflow) are really some of the biggest reasons python sucks in this way. They're the ones that cause most of the breakage. Starting with Nvidia making breaking changes, which then propagates to tensorflow et al, and then to enormous number of packages that depend on these fundamental packages. So to summarize, it's mostly Nvidia's fault.
acdha 4y ago
I’ve had that problem with Perl, too, so I think it’s more about which set of third-party packages you depend on and the norms in that space. One interesting tradeoff is that Python’s standard library is pretty large so you have a fair number of programs which can be frictionless by sticking to the stdlib.
driverdan 4y ago
This doesn't make sense. You can pin versions and it will work forever. If you want to update you need to update your code.
- skullone 4y ago
  Yah, nothing the GP says makes any sense. I've been working with large code bases with many languages for many years. None are perfect, but the GP makes no sense, sounds like poor decisions or poor code rather than a poor language.
  - chaxor 4y ago
    The idea that pinning versions and using environments will make your code run stable forever is very wrong (in python). You can't even get things to run for a few years this way. Many of the packages are simply not available anymore. Ever tried to get an environment running that uses qt4 on py2.7? It really wasn't that long ago that py2.7 was standard (in the stable code realm that we're talking about).
    - manfre 4y ago
      If you want a long term snapshot of other people's packages, the onus is on you to store them indefinitely. Packages can be pinned and installed from a local folder.
- Scarblac 4y ago
  Not forever, eg very old versions of Python cannot install dependencies from PyPI anymore because SSL is stricter nowadays.
  - hnews_account_1 4y ago
    I mean that level of breakage is good. You can’t keep running outdated stuff while expecting to interact with the wider world.
skullone 4y ago
Can you detail any of these "small and large breakages" or "bit rot"? It just doesn't jive with my experiences with any large code bases in nearly any language, python included.
- foresto 4y ago
  Python 3.10 introduced asyncio changes that broke compatibility with earlier 3.x releases. I don't have the details at hand, but as I recall, some code that supported caller-supplied event loops not only broke, but could no longer be made compatible with both old 3.x and new 3.x python versions (unless separate code paths were maintained). This was frustrating, because I don't expect point-releases to break the standard library, let alone require a code fork to maintain cross-distro compatibility. It was disappointing, because I had never encountered such breakage from python while Guido was still in charge.
  - qwertox 4y ago
    I had the same experience. I was pretty annoyed to see that some server apps were unable to run after the upgrade because of some changes to the loop. "Why?", I was asking myself.
nicoco 4y ago
For a different perspective, I started using python about 5 years ago, and I never experienced a single breakage due to a new python release. Instead, I'm always excited to read new version releases notes and it's the only thing that may make me move away from debian stable someday. But waiting a few months, using containers, or compiling a newer python is usually fine when I can't wait. Removing deprecated stuff is… the point of deprecating stuff?
- mrelectric 4y ago
  conda create -n yourenv python=3. 12 ;)
- leadingthenet 4y ago
  You should also look into pyenv if you'd like to install newer versions sooner, outside a container.
  - rch 4y ago
    I moved to nixpkgs from pyenv about a year ago, with positive results. I think it's worth the initial effort.
- Alex3917 4y ago
  Same here. I don't think I've been affected by a single deprecation since upgrading to Python3 in 2015, and even that upgrade wasn't that difficult -- mainly I was just forced to fix a few things I had been doing incorrectly, which imho is a good thing.
- cogman10 4y ago
  > Removing deprecated stuff is… the point of deprecating stuff? The point of deprecating stuff is to redirect to newer/better/saner APIs, not necessarily removing the thing. This is where I like Java's approach. Stuff is deprecated in the JDK but fairly rarely is it removed. When it is, it's because the feature is either unused or so detrimental to the ecosystem as to warrant removal (see: finalizers).
mattgreenrocks 4y ago
Agree. This is perfectly exemplified by Python 3's insistence that you call print with parenthesis: >>> print "hello" SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)? I empathize with the lang devs in that having two forms of print is nonoptimal, but the fact it tells you to do something different while fully understanding what you said (as it were) is what really irritates me. It comes off feeling needlessly pedantic for the language.
- whimsicalism 4y ago
  I disagree strongly with this take and it seems basically to be saying "better error messages are bad." What if clang says "did you forget a ';'"? It would have been better to just compile the code as if there was a semicolon?
  - johnchristopher 4y ago
    > I disagree strongly with this take and it seems basically to be saying "better error messages are bad." I rather have something like this: > Use exit() or Ctrl-D (i.e. EOF) to exit > >>> Less pedantic, less passive agressive. Doesn't fake being nice to the user.
  - sigmoid10 4y ago
    No need to disagree, that's just two different design patterns among programming languages. If stuff like that matters, you can always choose Ruby or something similar. It has its own shortcomings though and neither approach is ideal in every situation. That being said, the transition from Python 2 to 3 was the most horrible thing that ever happened to a popular language. Print for example was fine as a keyword and forcing it into a function after so many years was a terrible retroactive design choice.
    - ywain 4y ago
      Meh, the print change was fairly trivial. You could backport the print function in Python 2 codebases, and updating existing print statements to use the function was easy to automate. String changing from bytes to Unicode was a lot more painful, in my experience.
derefr 4y ago
> By comparison, I never experienced such churn with perl. Ah, but that's because the Perl community rejected the one major attempt at such a change (Perl 6) so hard that it became its own separate language.
js2 4y ago
Other than the 2 to 3 transition, doesn't jive with my experience as a developer who's used Python in various projects for over 20 years (since the 1.5.2 days). I've dealt with a lot of sideways yak-shaving work in my career and still frequently today and Python has been the absolute least of it.
ajsnigrutin 4y ago
> By comparison, I never experienced such churn with perl. I literally have 20+ years old perl scripts, usually doing one single thing (many of them) still working on new machines without issues. I've rewritten some stuff from python(2) to perl (instead of python3) because i was unsure when a new rewrite for whatever reasons... Now, more python stuff needs fixing, while perl still works.
- namrog84 4y ago
  Your kinda comparing simple basic api in perl vs likely more complicated python code here aren't you? If you had a set of single simple python functions maybe they wouldn't have broke as much if at all?
  - ajsnigrutin 4y ago
    > If you had a set of single simple python functions maybe they wouldn't have broke as much if at all? Like (python 2): print "hello world!" ? ( https://docs.python.org/2/tutorial/introduction.html https://docs.python.org/2/tutorial/introduction.html )
    - camdenreslink 4y ago
      Python 3 came out 14 years ago, and changing the syntax of one function wasn’t even a big deal then. Literally a 10 minute code search to fix a project. It might be time to move on…
      - ajsnigrutin 4y ago
        It was literally months to fix every change in every project and to fix all the issues coming from that. ("print" wasn't the only change in 2->3) Our codebase is was (and is) old, but the forced change came recently, when ubuntu decided to remove python 2 support (ubuntu 20.04?). And when ubuntu decides that they want python >=3.12 as the only version installed, this means another change and more work to fix stuff that worked just fine.
- 4y ago
smeagull 4y ago
I missing print without parentheses.
- vram22 4y ago
  Me three, oops, meant two (extra parentheses to type). Not /s, but ;)
musicale 4y ago
The only language I've experienced so much churn with is Swift (which loves to break things, vs. the relative stability of Objective-C.) But Apple has already outsourced yearly iOS compatibility updates onto every developer, and now they have even decided to remove apps that haven't been updated recently from the app store. A stable game/app development platform it is not. I am still shocked though by the Python project deciding to break billions of lines of legacy code. What other platforms demonstrate that kind of contempt for their developers? Removing the print statement seems like a particularly negative trade-off: breaking code in the name of syntactic purity, instead of simply deprecating the print statement and letting it live on compatibly with the print() function. Since then a bunch of new syntax (not all of which is bad) has of course been added. It's also weird that until now they seem to have largely ignored performance and focused on adding random new features.

forgotmypw17 4y ago

This is the top reason I chose Perl for my project. Literally every time I try to use someone else's Python code from GitHub I run into this crap. I wanted my project to be easy to install and run, so I chose Perl.

jjgreen 4y ago
I have had Perl scripts which I've not used for 15 years, run them expecting to need to fix something, but nothing needed ...
- somat 4y ago
  The really nice part of sticking with python2 is that it is now a a stable interface. just like perl 5. only half joking.
  - forgotmypw17 4y ago
    I would consider it, except it is no longer being installed most places, since it is "deprecated".
wakeupcall 4y ago
It's a real shame, since this is a project management issue. You'd expect python to be a stable language given its age. I expected that to be the case at 2.7. Then at 3.1. At 3.12 it's still not the case. It's reasonable to expect this is not going to change.
- forgotmypw17 4y ago
  I think with backwards compatibility it's "fool me once". In order to make the most of Lindy Effect, I avoid any dependencies with less than 20 years of backwards compatibility. For some that means a subset of features. For some like Python it means any python scripts must be optional and have Perl duplicates.
- chaxor 4y ago
  It's gotten far, FAR worse since Guido stopped having as much guidance. The increase in mandatory updates at regular intervals is a recipe for disaster in most cases, as it is in python. Also, to pile on top of the stdlib problems - it's probably clear to most everyone at this point - but NVIDIA and Google (tensorflow) are really some of the biggest reasons python sucks in this way. They're the ones that cause most of the breakage. Starting with Nvidia making breaking changes, which then propagates to tensorflow et al, and then to enormous number of packages that depend on these fundamental packages. So to summarize, it's mostly Nvidia's fault.

acdha 4y ago

I’ve had that problem with Perl, too, so I think it’s more about which set of third-party packages you depend on and the norms in that space. One interesting tradeoff is that Python’s standard library is pretty large so you have a fair number of programs which can be frictionless by sticking to the stdlib.

driverdan 4y ago

This doesn't make sense. You can pin versions and it will work forever. If you want to update you need to update your code.

skullone 4y ago
Yah, nothing the GP says makes any sense. I've been working with large code bases with many languages for many years. None are perfect, but the GP makes no sense, sounds like poor decisions or poor code rather than a poor language.
- chaxor 4y ago
  The idea that pinning versions and using environments will make your code run stable forever is very wrong (in python). You can't even get things to run for a few years this way. Many of the packages are simply not available anymore. Ever tried to get an environment running that uses qt4 on py2.7? It really wasn't that long ago that py2.7 was standard (in the stable code realm that we're talking about).
  - manfre 4y ago
    If you want a long term snapshot of other people's packages, the onus is on you to store them indefinitely. Packages can be pinned and installed from a local folder.
Scarblac 4y ago
Not forever, eg very old versions of Python cannot install dependencies from PyPI anymore because SSL is stricter nowadays.
- hnews_account_1 4y ago
  I mean that level of breakage is good. You can’t keep running outdated stuff while expecting to interact with the wider world.

skullone 4y ago

Can you detail any of these "small and large breakages" or "bit rot"? It just doesn't jive with my experiences with any large code bases in nearly any language, python included.

foresto 4y ago
Python 3.10 introduced asyncio changes that broke compatibility with earlier 3.x releases. I don't have the details at hand, but as I recall, some code that supported caller-supplied event loops not only broke, but could no longer be made compatible with both old 3.x and new 3.x python versions (unless separate code paths were maintained). This was frustrating, because I don't expect point-releases to break the standard library, let alone require a code fork to maintain cross-distro compatibility. It was disappointing, because I had never encountered such breakage from python while Guido was still in charge.
- qwertox 4y ago
  I had the same experience. I was pretty annoyed to see that some server apps were unable to run after the upgrade because of some changes to the loop. "Why?", I was asking myself.

nicoco 4y ago

For a different perspective, I started using python about 5 years ago, and I never experienced a single breakage due to a new python release. Instead, I'm always excited to read new version releases notes and it's the only thing that may make me move away from debian stable someday. But waiting a few months, using containers, or compiling a newer python is usually fine when I can't wait. Removing deprecated stuff is… the point of deprecating stuff?

mrelectric 4y ago
conda create -n yourenv python=3. 12 ;)
leadingthenet 4y ago
You should also look into pyenv if you'd like to install newer versions sooner, outside a container.
- rch 4y ago
  I moved to nixpkgs from pyenv about a year ago, with positive results. I think it's worth the initial effort.
Alex3917 4y ago
Same here. I don't think I've been affected by a single deprecation since upgrading to Python3 in 2015, and even that upgrade wasn't that difficult -- mainly I was just forced to fix a few things I had been doing incorrectly, which imho is a good thing.
cogman10 4y ago
> Removing deprecated stuff is… the point of deprecating stuff? The point of deprecating stuff is to redirect to newer/better/saner APIs, not necessarily removing the thing. This is where I like Java's approach. Stuff is deprecated in the JDK but fairly rarely is it removed. When it is, it's because the feature is either unused or so detrimental to the ecosystem as to warrant removal (see: finalizers).

mattgreenrocks 4y ago

Agree. This is perfectly exemplified by Python 3's insistence that you call print with parenthesis: >>> print "hello" SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)? I empathize with the lang devs in that having two forms of print is nonoptimal, but the fact it tells you to do something different while fully understanding what you said (as it were) is what really irritates me. It comes off feeling needlessly pedantic for the language.

whimsicalism 4y ago
I disagree strongly with this take and it seems basically to be saying "better error messages are bad." What if clang says "did you forget a ';'"? It would have been better to just compile the code as if there was a semicolon?
- johnchristopher 4y ago
  > I disagree strongly with this take and it seems basically to be saying "better error messages are bad." I rather have something like this: > Use exit() or Ctrl-D (i.e. EOF) to exit > >>> Less pedantic, less passive agressive. Doesn't fake being nice to the user.
- sigmoid10 4y ago
  No need to disagree, that's just two different design patterns among programming languages. If stuff like that matters, you can always choose Ruby or something similar. It has its own shortcomings though and neither approach is ideal in every situation. That being said, the transition from Python 2 to 3 was the most horrible thing that ever happened to a popular language. Print for example was fine as a keyword and forcing it into a function after so many years was a terrible retroactive design choice.
  - ywain 4y ago
    Meh, the print change was fairly trivial. You could backport the print function in Python 2 codebases, and updating existing print statements to use the function was easy to automate. String changing from bytes to Unicode was a lot more painful, in my experience.

derefr 4y ago

> By comparison, I never experienced such churn with perl. Ah, but that's because the Perl community rejected the one major attempt at such a change (Perl 6) so hard that it became its own separate language.

js2 4y ago

Other than the 2 to 3 transition, doesn't jive with my experience as a developer who's used Python in various projects for over 20 years (since the 1.5.2 days). I've dealt with a lot of sideways yak-shaving work in my career and still frequently today and Python has been the absolute least of it.

ajsnigrutin 4y ago

> By comparison, I never experienced such churn with perl. I literally have 20+ years old perl scripts, usually doing one single thing (many of them) still working on new machines without issues. I've rewritten some stuff from python(2) to perl (instead of python3) because i was unsure when a new rewrite for whatever reasons... Now, more python stuff needs fixing, while perl still works.

namrog84 4y ago
Your kinda comparing simple basic api in perl vs likely more complicated python code here aren't you? If you had a set of single simple python functions maybe they wouldn't have broke as much if at all?
- ajsnigrutin 4y ago
  > If you had a set of single simple python functions maybe they wouldn't have broke as much if at all? Like (python 2): print "hello world!" ? ( https://docs.python.org/2/tutorial/introduction.html https://docs.python.org/2/tutorial/introduction.html )
  - camdenreslink 4y ago
    Python 3 came out 14 years ago, and changing the syntax of one function wasn’t even a big deal then. Literally a 10 minute code search to fix a project. It might be time to move on…
    - ajsnigrutin 4y ago
      It was literally months to fix every change in every project and to fix all the issues coming from that. ("print" wasn't the only change in 2->3) Our codebase is was (and is) old, but the forced change came recently, when ubuntu decided to remove python 2 support (ubuntu 20.04?). And when ubuntu decides that they want python >=3.12 as the only version installed, this means another change and more work to fix stuff that worked just fine.
4y ago

smeagull 4y ago

I missing print without parentheses.

vram22 4y ago
Me three, oops, meant two (extra parentheses to type). Not /s, but ;)

musicale 4y ago

The only language I've experienced so much churn with is Swift (which loves to break things, vs. the relative stability of Objective-C.) But Apple has already outsourced yearly iOS compatibility updates onto every developer, and now they have even decided to remove apps that haven't been updated recently from the app store. A stable game/app development platform it is not. I am still shocked though by the Python project deciding to break billions of lines of legacy code. What other platforms demonstrate that kind of contempt for their developers? Removing the print statement seems like a particularly negative trade-off: breaking code in the name of syntactic purity, instead of simply deprecating the print statement and letting it live on compatibly with the print() function. Since then a bunch of new syntax (not all of which is bad) has of course been added. It's also weird that until now they seem to have largely ignored performance and focused on adding random new features.