Re: [PATCH] python: prioritize python 3.x over 2.x

[Zack Weinberg]

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