On Wed, Jan 26, 2022, at 10:10 PM, Mike Frysinger wrote: > On 26 Jan 2022 10:07, Zack Weinberg wrote: >> Please also move the plain "python" command down to the python2 >> block (right after "python2" would be the best place I think). Any >> system on which "python" runs Python 3 is grossly misconfigured. > > i don't think that's accurate. Python PEP-0394 explicitly permits > `python` to be any version, and many distros do just that
Yes, I know. PEP 394 is wrong. Its authors grossly underestimated the volume of Python 2 code that still exists today and, if accidentally executed with a v3 interpreter, will *silently* malfunction -- not just crashing, but corrupting data with no warning. I had to deal with this kind of code all the time in my previous day job and I'm still quite peeved that the Python devs blew me off about it. What PEP 394 *should* have said is that the command name "python" and the #! path /usr/bin/python MUST[rfc2119] be *permanently reserved* for the Python 2.7 interpreter, and "python3" is the only acceptable not-specifically-versioned command name for the 3.x interpreter, even in virtualenvs. > distros that remove `python` entirely as part of Python 2 removal > are doing it wrong. On the contrary, those distros are the only ones doing it right. Now, nobody listens to me, and I'm painfully aware that "python" pointing to Python 3 is common, but that doesn't mean Autotools should make the situation even worse. Autotools should, on its own motion, discourage the use of "python". Thus, my suggested changes. > if your argument is that language incompatibilities make supporting > Python 2 and Python 3 with a single interpreter name either > difficult or impossible (due to incompatible syntax changes), i'll > remind you that Python 3 is not actually that much better here. No, my argument is that there is a huge (millions of lines of code at least) installed base of programs written for Python 2 string semantics, that may *never* be updated to Python 3, and that can *silently corrupt data* if executed by accident with a v3 interpreter. They run without complaint but they do the Wrong Thing. (Whether you've ever seen such a program strongly depends on the circles you work in. It's possible to code defensively enough that your Python 2 programs crash reliably under the v3 interpreter, and I expect most *packaged* software is written by people who do that without even thinking about it, so you might not realize it's possible to get the silent data corruption, but in the land of one-off unpackaged scripts (that nonetheless need to work reliably for decades) this phenomenon is everywhere.) > the Python 3.0 - 3.8 series might have been *mostly* stable to try > and encourage people to migrate off of Python 2.7, there were > versions that changed syntax and broke things, and it's only going > to get worse now that Python 2.7 is "gone". off the top of my head, > Python 3.5 added type hints, and Python 3.7 added async/await > keywords. both of those completely break in older versions of > Python 3. As far as I know these things can only cause SyntaxError crashes if you run a program with an interpreter that's too old, not silent data corruption, so it's not at all the same thing in my book. zw
