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