4 ms·

> 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 somethi

> 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.
- Daishiman 5y ago
  > 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. On Linux land projects that depend on system libraries and `*-dev` packages break constantly across major versions. > That's a workaround. A solution would have allowed python 2 & 3 to coexist with no additional effort. You can do that if you make your python interpreter version explicit in your shebang. > 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. A toolset that gave you a decade to upgrade with ample warnings is the opposite of fragile.
- dragonwriter 5y ago
  > 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. The only solution to that is neve breaking backward compatibility because either someone might prematurely upgrade (not what happened woth Ubuntu) or someone might not maintain software (what seems to have happened with the third party tools in question, whether it was the original maintainer or some packager or...) and might also not vendor dependencies, on the assumption that external environments will never change. > A solution would have allowed python 2 & 3 to coexist with no additional effort. PEP394 allows that, if you depend on a particular python major version use “python2” and “python3” to refer to it: both side by aide installation and continuity of operation over the time “python” switches from 2 to 3 is provided. While some linux distros broke the recommendation on when to switch “python” targets, that would be transparent to anyone following the recommendation.

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.

Daishiman 5y ago
> 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. On Linux land projects that depend on system libraries and `*-dev` packages break constantly across major versions. > That's a workaround. A solution would have allowed python 2 & 3 to coexist with no additional effort. You can do that if you make your python interpreter version explicit in your shebang. > 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. A toolset that gave you a decade to upgrade with ample warnings is the opposite of fragile.
dragonwriter 5y ago
> 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. The only solution to that is neve breaking backward compatibility because either someone might prematurely upgrade (not what happened woth Ubuntu) or someone might not maintain software (what seems to have happened with the third party tools in question, whether it was the original maintainer or some packager or...) and might also not vendor dependencies, on the assumption that external environments will never change. > A solution would have allowed python 2 & 3 to coexist with no additional effort. PEP394 allows that, if you depend on a particular python major version use “python2” and “python3” to refer to it: both side by aide installation and continuity of operation over the time “python” switches from 2 to 3 is provided. While some linux distros broke the recommendation on when to switch “python” targets, that would be transparent to anyone following the recommendation.