5 ms·

This exaggeration of Python3 migration is ridiculous and frankly has become boring. Yes, Python 3 broke compatibility. But we had more than a decade to migrate.

by pcx 5y ago

This exaggeration of Python3 migration is ridiculous and frankly has become boring. Yes, Python 3 broke compatibility. But we had more than a decade to migrate. It definitely does not deserve to be the poster child for migrations gone wrong.

whatshisface 5y ago
The python language developers did not do it wrong. The community of python users, which include companies with ten year old unmaintained scripts, did not want it invest to transition until the absolute last second. The "Apple Solution" is to make the last second the first second. Who knows if that's the right thing to do.
- fnord123 5y ago
  The python language developers absolutely did do it wrong. You could not run mixed python2 and python3 code. Either all your dependencies were migrated and you could flip the switch and try things out, or some stragglers kept you running code with compatibilities for 2 and 3 while you waited. And if one of your dependencies started using new features from 3.x it would break everyone stuck on 2.7, so you can't even use the new features in your library. So why would you bother migrating? So everyone was stuck in a game theoretical position where there was no first mover advantage because one straggler would invalidate all the investment.
  - ric2b 5y ago
    > So everyone was stuck in a game theoretical position where there was no first mover advantage because one straggler would invalidate all the investment. Clearly not, as most libraries are now Python 3 only, so the switch did happen. I do see a lot of people complaining but I see no practical solutions being suggested. "Just don't do a breaking change" isn't a practical solution when the problem being fixed was such a core feature of every language, strings.
    - fnord123 5y ago
      >Clearly not, as most libraries are now Python 3 only, so the switch did happen. You don't build a convincing argument that the python developers did nothing wrong when saying this 1.5 years after python 2.7 has been EOL. >I do see a lot of people complaining but I see no practical solutions being suggested. "Just don't do a breaking change" isn't a practical solution when the problem being fixed was such a core feature of every language, strings. A system should have been put in place to allow python3 code to import python2 code. Then people have an incentive to actually run python3 and use python3 features. More people are stuck on Java8 which has been EOL for a very long time. They are often stuck because Android hasn't upgraded afaik. But Java11, 14, etc can use almost all Java8 code unless it uses I think sun.misc.Unsafe or something like that. The point is that people can use modern Javas with Java libraries targeting older versions.
- josefx 5y ago
  > The community of python users, which include companies with ten year old unmaintained scripts, did not want it invest to transition until the absolute last second. Try shipping python3 scripts to systems that only have python2 interpreters. Doesn't work very well unless you also start to ship the interpreter and all its dependencies. I learned my lesson and just avoid distributing any Python code to customers now.
  - ric2b 5y ago
    What language lets you ship scripts that use features of version X and also works on versions <X? Docker tends to be the easy solution for all this stuff, and it's language agnostic. > Doesn't work very well unless you also start to ship the interpreter and all its dependencies. That basically applies to everything that isn't a statically linked binary.
    - fnord123 5y ago
      Agree with you here. If you try to deploy a C program to ancient centos then it can also fail with glibc being incompatible. https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-library-handles-backward-compatibility https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-...
      - josefx 5y ago
        But it will run on a modern system if you compiled it against the CentOS version. I have a VM running to do just that. Trying to run Python 2 code on a modern runtime on the other hand will have the Python community feed your remains to the pigs.
      - nonameiguess 5y ago
        Much different from Python, though. As long as you compile your C program against the same version of libc you're running against, the program will still work, no matter how old the code. You just can't run a program that was compiled against an incompatible libc. A Python 2 interpreter can't run Python 3 code, and vice versa, no matter what, because the actual language changed.
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
rpastuszak 5y ago
I'm starting to think that everyone would be less outraged if they rebranded python3 to <insert_different_snake_here>
- sealjam 5y ago
  Shouldn't that be <insert_different_british_comedy_troupe>?
  - DaiPlusPlus 5y ago
    The Mighty Boosh just isn’t the same
    - rpastuszak 5y ago
      I don't like overly tech-specific job titles, but "lead mighty boosh developer" sounds wonderful. Every person saying "pythonic" instead of idiomatic would need to switch to "booshy" instead. The file extension would be .og (for old Greg). Only pair programming would suffer as the main philosophy of the language would we coding in isolation.
      - DaiPlusPlus 5y ago
        > Only pair programming would suffer as the main philosophy of the language would we coding in isolation. Well, that, and the constant drinking of Baileys from a shoe...
- heavyset_go 5y ago
  Look at how well that's worked out for Perl and Raku.
  - hobofan 5y ago
    The Raku name was adopted not even 2 years ago, and it's not really the most popular programming language niche anyways.
morelisp 5y ago
It is easy to look at Python 3.x today and say the migration should have been easy, but some of us were there, and remember how intransigent some core devs were about things like u"" and %, and how Python 3 offered nothing better upon release. https://news.ycombinator.com/item?id=22036773 https://news.ycombinator.com/item?id=22036773
- TylerE 5y ago
  Not to mention, as the cherry on the turd sandwich, performance of early 3.x versions was substantially worse than 2.7.
  - fpoling 5y ago
    And it is still slower for small glue scripts. On my Windows 10 box hello, world script finishes with Python2 in 73 microseconds (the best time of 5 runs) versus 238 ms for Python3. That translates into noticeable slowdown of compilation time for a project extensively using python code in the build system.
coliveira 5y ago
It is not an exaggeration, the Python3 move was one of the worst releases ever in terms of managing the process. It took a decade for library creators to have it all settled. It was not end users fault that they depended on libraries that wouldn't upgrade for several years.
zdiscov 5y ago
The philosophy of incompatible upgrades is brutal for popular languages, IMO. The main issue is not that I give you X amount of time now please fix it coz you have generous time now. The cost of such a change is ENORMOUS. As an example, in a recently IPO'd company we had a team of engineers and we had 6 months of work for 10 engineers, round the clock, to fix the Python 2 to Python 3 migration issues alone! and the original creators of the code were long gone! .. and I could only imagine the plight of thousands of other folks in similar boats and other resource constrained boat-less entities! Then there are distributed packages and libraries that are used by a large set of audience that are dev complete and no longer maintained as such. The cost of fixing those are much much higher. It makes one more than wince at the thought of going through this exercise again.
fpoling 5y ago
The problem was not that Python3 had broken things. The problem was the scale of breakage and inability to use both python2 and python3 code. Moreover only after a few years since Python3 release it became possible to write libraries compatible with both Python2 and 3.

by pcx 5y ago

whatshisface 5y ago

The python language developers did not do it wrong. The community of python users, which include companies with ten year old unmaintained scripts, did not want it invest to transition until the absolute last second. The "Apple Solution" is to make the last second the first second. Who knows if that's the right thing to do.

fnord123 5y ago
The python language developers absolutely did do it wrong. You could not run mixed python2 and python3 code. Either all your dependencies were migrated and you could flip the switch and try things out, or some stragglers kept you running code with compatibilities for 2 and 3 while you waited. And if one of your dependencies started using new features from 3.x it would break everyone stuck on 2.7, so you can't even use the new features in your library. So why would you bother migrating? So everyone was stuck in a game theoretical position where there was no first mover advantage because one straggler would invalidate all the investment.
- ric2b 5y ago
  > So everyone was stuck in a game theoretical position where there was no first mover advantage because one straggler would invalidate all the investment. Clearly not, as most libraries are now Python 3 only, so the switch did happen. I do see a lot of people complaining but I see no practical solutions being suggested. "Just don't do a breaking change" isn't a practical solution when the problem being fixed was such a core feature of every language, strings.
  - fnord123 5y ago
    >Clearly not, as most libraries are now Python 3 only, so the switch did happen. You don't build a convincing argument that the python developers did nothing wrong when saying this 1.5 years after python 2.7 has been EOL. >I do see a lot of people complaining but I see no practical solutions being suggested. "Just don't do a breaking change" isn't a practical solution when the problem being fixed was such a core feature of every language, strings. A system should have been put in place to allow python3 code to import python2 code. Then people have an incentive to actually run python3 and use python3 features. More people are stuck on Java8 which has been EOL for a very long time. They are often stuck because Android hasn't upgraded afaik. But Java11, 14, etc can use almost all Java8 code unless it uses I think sun.misc.Unsafe or something like that. The point is that people can use modern Javas with Java libraries targeting older versions.
josefx 5y ago
> The community of python users, which include companies with ten year old unmaintained scripts, did not want it invest to transition until the absolute last second. Try shipping python3 scripts to systems that only have python2 interpreters. Doesn't work very well unless you also start to ship the interpreter and all its dependencies. I learned my lesson and just avoid distributing any Python code to customers now.
- ric2b 5y ago
  What language lets you ship scripts that use features of version X and also works on versions <X? Docker tends to be the easy solution for all this stuff, and it's language agnostic. > Doesn't work very well unless you also start to ship the interpreter and all its dependencies. That basically applies to everything that isn't a statically linked binary.
  - fnord123 5y ago
    Agree with you here. If you try to deploy a C program to ancient centos then it can also fail with glibc being incompatible. https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-library-handles-backward-compatibility https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-...
    - josefx 5y ago
      But it will run on a modern system if you compiled it against the CentOS version. I have a VM running to do just that. Trying to run Python 2 code on a modern runtime on the other hand will have the Python community feed your remains to the pigs.
    - nonameiguess 5y ago
      Much different from Python, though. As long as you compile your C program against the same version of libc you're running against, the program will still work, no matter how old the code. You just can't run a program that was compiled against an incompatible libc. A Python 2 interpreter can't run Python 3 code, and vice versa, no matter what, because the actual language changed.
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]

rpastuszak 5y ago

I'm starting to think that everyone would be less outraged if they rebranded python3 to <insert_different_snake_here>

sealjam 5y ago
Shouldn't that be <insert_different_british_comedy_troupe>?
- DaiPlusPlus 5y ago
  The Mighty Boosh just isn’t the same
  - rpastuszak 5y ago
    I don't like overly tech-specific job titles, but "lead mighty boosh developer" sounds wonderful. Every person saying "pythonic" instead of idiomatic would need to switch to "booshy" instead. The file extension would be .og (for old Greg). Only pair programming would suffer as the main philosophy of the language would we coding in isolation.
    - DaiPlusPlus 5y ago
      > Only pair programming would suffer as the main philosophy of the language would we coding in isolation. Well, that, and the constant drinking of Baileys from a shoe...
heavyset_go 5y ago
Look at how well that's worked out for Perl and Raku.
- hobofan 5y ago
  The Raku name was adopted not even 2 years ago, and it's not really the most popular programming language niche anyways.

morelisp 5y ago

It is easy to look at Python 3.x today and say the migration should have been easy, but some of us were there, and remember how intransigent some core devs were about things like u"" and %, and how Python 3 offered nothing better upon release. https://news.ycombinator.com/item?id=22036773 https://news.ycombinator.com/item?id=22036773

TylerE 5y ago
Not to mention, as the cherry on the turd sandwich, performance of early 3.x versions was substantially worse than 2.7.
- fpoling 5y ago
  And it is still slower for small glue scripts. On my Windows 10 box hello, world script finishes with Python2 in 73 microseconds (the best time of 5 runs) versus 238 ms for Python3. That translates into noticeable slowdown of compilation time for a project extensively using python code in the build system.

coliveira 5y ago

It is not an exaggeration, the Python3 move was one of the worst releases ever in terms of managing the process. It took a decade for library creators to have it all settled. It was not end users fault that they depended on libraries that wouldn't upgrade for several years.

zdiscov 5y ago

The philosophy of incompatible upgrades is brutal for popular languages, IMO. The main issue is not that I give you X amount of time now please fix it coz you have generous time now. The cost of such a change is ENORMOUS. As an example, in a recently IPO'd company we had a team of engineers and we had 6 months of work for 10 engineers, round the clock, to fix the Python 2 to Python 3 migration issues alone! and the original creators of the code were long gone! .. and I could only imagine the plight of thousands of other folks in similar boats and other resource constrained boat-less entities! Then there are distributed packages and libraries that are used by a large set of audience that are dev complete and no longer maintained as such. The cost of fixing those are much much higher. It makes one more than wince at the thought of going through this exercise again.

fpoling 5y ago

The problem was not that Python3 had broken things. The problem was the scale of breakage and inability to use both python2 and python3 code. Moreover only after a few years since Python3 release it became possible to write libraries compatible with both Python2 and 3.