5 ms·

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 cos

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
      > That's not really a problem because the Python maintainers conveniently provided a package to do trivial 2-to-3 migrations. That's not the point. For example, when ubuntu dropped python 2.x as the default, some of my workflows got broken because of scripts which I didn't write and didn't even know about. There's plenty of old code which people still depend on. System upgrades should not break your projects, or require you to go in and do surgery on scripts you didn't write. > 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. That's a workaround. A solution would have allowed python 2 & 3 to coexist with no additional effort. > If you're executing a script, Python supports shebang notation to determine your executable. Again, you're depending on the people who wrote the python code you depend on to handle this in the correct way. It's not something which is built into the ecosystem. I'm sorry, but all your arguments seem to boil down to the fact that there are ways to make python usable despite the extreme fragility of the toolset.

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
    > That's not really a problem because the Python maintainers conveniently provided a package to do trivial 2-to-3 migrations. That's not the point. For example, when ubuntu dropped python 2.x as the default, some of my workflows got broken because of scripts which I didn't write and didn't even know about. There's plenty of old code which people still depend on. System upgrades should not break your projects, or require you to go in and do surgery on scripts you didn't write. > 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. That's a workaround. A solution would have allowed python 2 & 3 to coexist with no additional effort. > If you're executing a script, Python supports shebang notation to determine your executable. Again, you're depending on the people who wrote the python code you depend on to handle this in the correct way. It's not something which is built into the ecosystem. I'm sorry, but all your arguments seem to boil down to the fact that there are ways to make python usable despite the extreme fragility of the toolset.