5 ms·

What gets me about it is that the 2/3 transition was just a massive unsolved problem, and one which caused pain over a decade after 3.x was released. Other eco

by skohan 5y ago

What gets me about it is that the 2/3 transition was just a massive unsolved problem, and one which caused pain over a decade after 3.x was released. Other ecosystems managed to solve it - like Rust for example handles editions in a very sound way - but with Python you had so many problems cropping up over the years over python versions.

formerly_proven 5y ago
Okay, I'm just going to call bullshit on this. There's this tiny, very-very vocal minority of people who continue to mystify the 2/3 changes and act as-if migrating code were some massively difficult herculean task that almost ended Python. Sometimes a little bit of "string/bytes split is ALL WRONG and utter non-sense!" mixed in. The truth is, that these were not actually big changes. The truth is that some orgs just wanna sit on their lazy asses doing jackshit to maintain their stuff and are surprised that, after 15 years, they have to do MAINTENANCE WORK??? ON THEIR CODE??? This is an outrage! The truth is that if porting was hard, or difficult, the code most likely had no meaningful tests, and so you couldn't do any changes anyway. The truth is, that changes like these expose bad engineering. And guess what, people don't like being exposed.
- kortex 5y ago
  Well, I think some companies had a massive conversion burden, but these are typically massive companies, like Google. Most companies had nowhere near as much python2 code. I think you hit the nail on the head with "lack of meaningful tests". The entirety of "locked to 2" python code I've dealt with was a serpentine mess with little/no tests and so brittle even going from print to logger risked things breaking. "But it currently works!"
  - rbanffy 5y ago
    > "But it currently works!" Miracles happen, but people shouldn't count on them.
- darkerside 5y ago
  I think most people rightly saw that the juice wasn't worth the squeeze for a 2/3 upgrade, and that the only reason we were going ahead with it was the sunk costs. If they wanted to create a new language that wasn't backwards compatible, why not make it a totally new and separate project?
  - drcongo 5y ago
    Because then they'd be maintaining two languages.
  - Daishiman 5y ago
    This is analogous to saying that if your code was running on IE6 then why bother upgrading it to run on newer versions of Firefox or Chrome. The only difference between the Python3 migration and other projects' major version changes (PHP5-7, .NET4 to newer versions, etc) is that migrating to Python 3 had the equivalent of a couple of major version's changes all rolled into one. Yes, it's painful; major version migrations are not easy. But it's really no different from not upgrading JS code to keep up with the latest browser security issues, or not upgrading your JVM (there are _tons_ of Java codebases stuck on ancient JVM versions). If you had a problem with migrating to Python 3 after a decade you would've still had the same problem with any other major software upgrade in your infra.
    - skohan 5y ago
      But a lot of python code is just scripts. Not everyone is going to go back and migrate every random script they wrote which just renames some files or something just because of "security issues" or something like that. Also versioning is not an issue, the problem is that Python didn't provide any viable versioning strategy. You just had two separate executables now, and you, as the user, have to decide where to put them in your $PATH and how to make sure the right code gets executed with the right version. That should have been baked into the language or the tooling itself.
      - Daishiman 5y ago
        > But a lot of python code is just scripts. Not everyone is going to go back and migrate every random script they wrote which just renames some files or something just because of "security issues" or something like that. That's not really a problem because the Python maintainers conveniently provided a package to do trivial 2-to-3 migrations. > Also versioning is not an issue, the problem is that Python didn't provide any viable versioning strategy. There were explicit backporting libraries created to manage the transition. Django depended on these for many years to succesfully support both Python 2 and Python 3 packages. > You just had two separate executables now, and you, as the user, have to decide where to put them in your $PATH and how to make sure the right code gets executed with the right version. That should have been baked into the language or the tooling itself. If you're executing a script, Python supports shebang notation to determine your executable. Sorry but none of these are real problems. The only place where you had migration issues were with very large packages that did complex string manipulation stuff, and that's the sort of code the requires maintenance in any language anyway. It's not like there isn't an enormous amount of precedent in these kinds of migrations (Ruby minor versions break. PHP's 4->5->7 migrations were huge).
- skohan 5y ago
  It's not about the code changes, it's about having to worry about two distinct and incompatible versions of python existing at the same time. So if I type `python` into the terminal, I don't know which programming language it's expecting without knowledge of the system. This is an especially bad problem with an interpreted language, since changing the system version of python can break code at a distance. I can run a program today and it works, and tomorrow it won't because somebody changed the symlink to the other python version. That's why there's this huge mess of environment management and containerization. I will give you an example of the problem. When ubuntu finally removed python 2.7 as the default, some of the workflows broke because scripts were depending on it. Scripts that I didn't write, or even know about. This is only a problem because nobody bothered to solve it. I think one correct solution for example would have been to have both python versions live inside the same executable, with some kind of flag or something added to run against python 3. Just some standardized way of handling the different versions would have made a huge difference and saved a decade of pain.
  - pseudalopex 5y ago
    PEP 394 was accepted in 2012. It says python2 should run Python 2 and python3 should run Python 3. Until 2019 it said python should run Python 2. And minor versions of Python 2 could be incompatible anyway. So the 2 to 3 transition didn't really change anything. Not depending on the system version of anything is normal advice for other interpreted languages too. Linux doesn't split shebang arguments. So you can't use env and pass a flag.
    - dragonwriter 5y ago
      > PEP 394 was accepted in 2012. It says python2 should run Python 2 and python3 should run Python 3. Until 2019 it said python should run Python 2. IIRC, there were a few linux distros that bucked this; at least one (Arch I think, but it wasn't one I used) switch “python” to Python 3 quite early, as I recall, and I think there were some others that did there own thing.
      - rbanffy 5y ago
- rbanffy 5y ago
  > MAINTENANCE WORK??? ON THEIR CODE??? This is an outrage! I usually keep a CI branch with dependencies unpinned (I made pip-chill for this use case) precisely to make sure I'll be the first to know when something coming from the future breaks my code. Being lazy is a virtue, but not if it cause an engineer to avoid work that needs to be done.

by skohan 5y ago

formerly_proven 5y ago

Okay, I'm just going to call bullshit on this. There's this tiny, very-very vocal minority of people who continue to mystify the 2/3 changes and act as-if migrating code were some massively difficult herculean task that almost ended Python. Sometimes a little bit of "string/bytes split is ALL WRONG and utter non-sense!" mixed in. The truth is, that these were not actually big changes. The truth is that some orgs just wanna sit on their lazy asses doing jackshit to maintain their stuff and are surprised that, after 15 years, they have to do MAINTENANCE WORK??? ON THEIR CODE??? This is an outrage! The truth is that if porting was hard, or difficult, the code most likely had no meaningful tests, and so you couldn't do any changes anyway. The truth is, that changes like these expose bad engineering. And guess what, people don't like being exposed.

kortex 5y ago
Well, I think some companies had a massive conversion burden, but these are typically massive companies, like Google. Most companies had nowhere near as much python2 code. I think you hit the nail on the head with "lack of meaningful tests". The entirety of "locked to 2" python code I've dealt with was a serpentine mess with little/no tests and so brittle even going from print to logger risked things breaking. "But it currently works!"
- rbanffy 5y ago
  > "But it currently works!" Miracles happen, but people shouldn't count on them.
darkerside 5y ago
I think most people rightly saw that the juice wasn't worth the squeeze for a 2/3 upgrade, and that the only reason we were going ahead with it was the sunk costs. If they wanted to create a new language that wasn't backwards compatible, why not make it a totally new and separate project?
- drcongo 5y ago
  Because then they'd be maintaining two languages.
- Daishiman 5y ago
  This is analogous to saying that if your code was running on IE6 then why bother upgrading it to run on newer versions of Firefox or Chrome. The only difference between the Python3 migration and other projects' major version changes (PHP5-7, .NET4 to newer versions, etc) is that migrating to Python 3 had the equivalent of a couple of major version's changes all rolled into one. Yes, it's painful; major version migrations are not easy. But it's really no different from not upgrading JS code to keep up with the latest browser security issues, or not upgrading your JVM (there are _tons_ of Java codebases stuck on ancient JVM versions). If you had a problem with migrating to Python 3 after a decade you would've still had the same problem with any other major software upgrade in your infra.
  - skohan 5y ago
    But a lot of python code is just scripts. Not everyone is going to go back and migrate every random script they wrote which just renames some files or something just because of "security issues" or something like that. Also versioning is not an issue, the problem is that Python didn't provide any viable versioning strategy. You just had two separate executables now, and you, as the user, have to decide where to put them in your $PATH and how to make sure the right code gets executed with the right version. That should have been baked into the language or the tooling itself.
    - Daishiman 5y ago
      > But a lot of python code is just scripts. Not everyone is going to go back and migrate every random script they wrote which just renames some files or something just because of "security issues" or something like that. That's not really a problem because the Python maintainers conveniently provided a package to do trivial 2-to-3 migrations. > Also versioning is not an issue, the problem is that Python didn't provide any viable versioning strategy. There were explicit backporting libraries created to manage the transition. Django depended on these for many years to succesfully support both Python 2 and Python 3 packages. > You just had two separate executables now, and you, as the user, have to decide where to put them in your $PATH and how to make sure the right code gets executed with the right version. That should have been baked into the language or the tooling itself. If you're executing a script, Python supports shebang notation to determine your executable. Sorry but none of these are real problems. The only place where you had migration issues were with very large packages that did complex string manipulation stuff, and that's the sort of code the requires maintenance in any language anyway. It's not like there isn't an enormous amount of precedent in these kinds of migrations (Ruby minor versions break. PHP's 4->5->7 migrations were huge).
skohan 5y ago
It's not about the code changes, it's about having to worry about two distinct and incompatible versions of python existing at the same time. So if I type `python` into the terminal, I don't know which programming language it's expecting without knowledge of the system. This is an especially bad problem with an interpreted language, since changing the system version of python can break code at a distance. I can run a program today and it works, and tomorrow it won't because somebody changed the symlink to the other python version. That's why there's this huge mess of environment management and containerization. I will give you an example of the problem. When ubuntu finally removed python 2.7 as the default, some of the workflows broke because scripts were depending on it. Scripts that I didn't write, or even know about. This is only a problem because nobody bothered to solve it. I think one correct solution for example would have been to have both python versions live inside the same executable, with some kind of flag or something added to run against python 3. Just some standardized way of handling the different versions would have made a huge difference and saved a decade of pain.
- pseudalopex 5y ago
  PEP 394 was accepted in 2012. It says python2 should run Python 2 and python3 should run Python 3. Until 2019 it said python should run Python 2. And minor versions of Python 2 could be incompatible anyway. So the 2 to 3 transition didn't really change anything. Not depending on the system version of anything is normal advice for other interpreted languages too. Linux doesn't split shebang arguments. So you can't use env and pass a flag.
  - dragonwriter 5y ago
    > PEP 394 was accepted in 2012. It says python2 should run Python 2 and python3 should run Python 3. Until 2019 it said python should run Python 2. IIRC, there were a few linux distros that bucked this; at least one (Arch I think, but it wasn't one I used) switch “python” to Python 3 quite early, as I recall, and I think there were some others that did there own thing.
    - rbanffy 5y ago
rbanffy 5y ago
> MAINTENANCE WORK??? ON THEIR CODE??? This is an outrage! I usually keep a CI branch with dependencies unpinned (I made pip-chill for this use case) precisely to make sure I'll be the first to know when something coming from the future breaks my code. Being lazy is a virtue, but not if it cause an engineer to avoid work that needs to be done.