LWN: Comments on "Revisiting PEP 394"

Revisiting PEP 394

anselm — Mon, 25 Mar 2019 14:53:59 +0000

“If you can't be a great success then at least try to be a horrible warning.”

Revisiting PEP 394

naptastic — Sun, 24 Mar 2019 15:09:12 +0000

s/total failure/research language/;

It's only a failure if you don't learn from it.

Have your cake and eat it too

ewen — Sat, 09 Mar 2019 01:07:01 +0000

Other than the 10 year old issue of creating a Python 3 that could not run a lot of Python 2 code (thus complicating "just upgrade" with lots of network effects), it seems to me that the remainder of this PEP 394 issue is a result of conflating two issues:

* What /usr/bin/python invokes (which is commonly in older #! lines); and

* What gets run when a user types "python" at the command line

For backwards compatibility, "#! /usr/bin/python" pretty much has to invoke a Python 2 compatible interpreter, or fail very obviously ("interpreter not found") for the foreseeable future (5+ years, maybe 10). Because (a) all the older not updated programs have "#! /usr/bin/python" in them, and (b) all the newer, updated, programs have "#! /usr/bin/python3" in them. So by definition anything invoking /usr/bin/python explicitly as its interpreter has not been updated for Some Time (tm).

But the discussion on this thread, and the discussion about PEP 394 updates in general, suggest that a lot of people would understandably like it if the user typing "python" at their command line invoked a recent version of Python, eg, Python 3.6 or Python 3.7 (or even Python 3.8 soon). At this point I'd like that too.

There is solution that achieves both of these problems:

1. /usr/bin/python points at /usr/bin/python2 if it is installed and is missing otherwise; *and*

2. There is a "python" program in *another directory on the default PATH* which points at /usr/bin/python3.

So running /usr/bin/python gets Python 2, and running "python" gets a modern Python 3+.

All this needs is another directory on the PATH earlier (even /usr/local/bin), and a "python" link in there which points at /usr/bin/python3. So, eg:

ln -s /usr/bin/python3 /usr/local/bin/python

installed as part of a "modern-python" type package would be sufficient to flip over what happens when you run "python".

There's a remaining surprise that "python" and "/usr/bin/python" are different, but it seems to me that's the *least* surprise possible in this situation, created over 10 years ago, of releasing a very incompatible successor to Python 2, ie Python 3. For better or worse, that degree of incompatibility permanently forked the language into Python 2 and Python 3; it's just that finally, 10 years later, the Python 3 fork is winning out.

Ewen

Revisiting PEP 394

mirabilos — Fri, 08 Mar 2019 19:51:26 +0000

While I admit I didn’t have *more* encoding problems with py3k than with Python, they were _much_ easier to fix in Python, while py3k tried too hard to do the thing it thought was right.

Some of the recent fixes will help, though.

Revisiting PEP 394

Cyberax — Fri, 08 Mar 2019 17:52:44 +0000

I never had an encoding problem with Py2. And yes, I’ve been using it for non-ASCII languages. The key is to stroke all strings in UTF-8 and suddenly all encoding issues disappear.

Revisiting PEP 394

moltonel — Fri, 08 Mar 2019 12:51:01 +0000

> I've started a couple of 100k line projects in Py2 during the last 3 years. Mwaahahaha! I hope to do more of that, Py2 must live forever!

Cobol is alive too, so python2 should be safe. I guess now's as good a time as any to set up your job security :p

Revisiting PEP 394

moltonel — Fri, 08 Mar 2019 12:39:32 +0000

> The thing is, Py2->3 porting does not give you any advantages. Py3 code is not safer or more concise, it doesn't provide you any new powerful abstractions. And for a long time it had been quite often slower than Py2 (it's _mostly_ fixed now).

I guess your python2 code never had an issue with text encoding ? Perhaps you were very careful to do all the correct calls where needed, or perhaps you were lucky with your input data. It's much harder to get things wrong with python3. To me that was py3's biggest selling point, but other people will have different favorite features (including some making code more concise or performant).

Also, it's unfair to complain that removal of deprecated stuff doesn't yield improvements on day 1. It takes time to take advantage of the cleaned up code. For example removing support for classic classes doesn't bring anything by itself, but it opens the door to improvements down the road.

Revisiting PEP 394

plugwash — Thu, 07 Mar 2019 17:00:49 +0000

It depends what you mean by "support".

If you mean patch critical security issues reported against the python2 packages in existing supported releases of the distro sure. Ubuntu 18.04 has python in it's main archive component and gets regular support until 2025. After that there is another 5 years of "extended security maintinance" but it is not clear what packages will be covered by that (and you have to pay for it).

If you mean support python2 in new releases of their distros going forward that becomes far less likely. The Debian/Ubuntu has stated they intend to remove python2 from main to universe in the next ubuntu LTS release. On the Debian side some lintian tags state that python2 is "likely to be removed after the release of buster", though time will tell how that actually pans out.

Revisiting PEP 394

Cyberax — Wed, 06 Mar 2019 18:45:00 +0000

> That might also be a consequence of Perl 6 being, in practical terms, a total failure for at least a decade.
Had Py2 been supported then Py3 would have been a similar "failure".

It also took almost 10 years for Py3 to gain serious traction.

Revisiting PEP 394

anton — Wed, 06 Mar 2019 17:40:10 +0000

or should we not assume that a program written for a system ought to work on another one ?

A program that works on a system ought to work on the next version of that system. If not, it's a regression of the system. That's the rule in Linux, and it's a good rule. PEP 394 also embodies this rule. Portability between different systems is nice to have, but a different issue.

As for not wanting to use "python3" to invoke the new language, there are ways to avoid that: e.g., call it "py", "pyt", or "boa". Or make "python" automagically select between the two languages (although automagic has its own pitfalls). But actually, what's so bad about using "python3" for the new language? You can introduce a shell alias if you don't like it.

My 30-years old script does work, because not everyone breaks backwards compatibility as cavalierly as you are advocating. Yes, there are cases where old stuff is broken by changes, but that's no excuse for more breaking changes.

And if you think that changing the hash-bang lines of the python 2 scripts still in use is not too bad, are you willing to pay the people who have to make these changes for the work this gratuitious change causes? Why should they pay for your dislike of the "python3" name?

Revisiting PEP 394

excors — Wed, 06 Mar 2019 11:55:31 +0000

That might also be a consequence of Perl 6 being, in practical terms, a total failure for at least a decade.

If I remember correctly, for years it existed only as documentation. Then there was the Parrot VM (which was meant to be generic enough to run any dynamic language including Perl 6, which in practice meant the VM developers just wrote a garbage-collected continuation-passing-style assembly language and didn't really care about any high-level language at all; and most of the work was done by two people, but they fell out and one quit). Then someone got fed up with the slow progress of Parrot and wrote Pugs (but that was more of a prototyping tool than a production-quality implementation, and it was written in Haskell so even fewer people would be able to contribute to it).

I stopped paying attention before Rakudo, which appears to be somewhat usable now (though with poor performance)? And apparently the Perl 6 language was declared stable in 2015, twelve years after the first Perl 6 book was published. But it's hard to lose such a long-standing well-deserved reputation as a joke and as a community that doesn't get things done.

In contrast, Python 3 had the misfortune of being successful. By the time people realised it was a terrible idea to break compatibility so heavily for such minor gains, it was too late to stop.

Revisiting PEP 394

Cyberax — Wed, 06 Mar 2019 10:40:34 +0000

> It is an advantage in the real world (as opposed to the fantasy world where Python 3 didn't happen), because Python 3 isn't going away – Python 2 is. Bitching and moaning won't change that.
I've started a couple of 100k line projects in Py2 during the last 3 years. Mwaahahaha! I hope to do more of that, Py2 must live forever!

> And guess what: PHP is still a terrible language :^)
Yes it is. Not that Python is much better now.

Perl developers also did all the right things:

1) They hard-forked the language. But Perl5 is supported and is being improved all the time. The current Perl5 interpreter is much faster than 10 years ago, for example. In contrast, Python developers abandoned the Py2 code base (only occasionally shitting on it to break existing software).

2) They used a language fork as an excuse to drastically improve the language: Perl6 has no GIL, it has truly well thought out Unicode support and the language itself has been regularized. Initial 4 versions of Python 3 had no real improvements whatsoever compared to Py2.

3) There's no drive to force everyone to forget Perl 5. No self-celebratory sites "Perl5 days to death" or any other such nonsense.

Revisiting PEP 394

anselm — Wed, 06 Mar 2019 10:27:26 +0000

This is not an "advantage", it's simply an inevitable forced churn.

It is an advantage in the real world (as opposed to the fantasy world where Python 3 didn't happen), because Python 3 isn't going away – Python 2 is. Bitching and moaning won't change that.

PHP (amazingly) did the right thing by abandoning PHP6 and instead focusing on improving existing version.

And guess what: PHP is still a terrible language :^)

Revisiting PEP 394

Cyberax — Wed, 06 Mar 2019 01:00:01 +0000

> These days if you want up-to-date third-party library support then Python 3 is pretty much required.
This is not an "advantage", it's simply an inevitable forced churn.

> Not just “fixed”. In various important areas, Python 3 is now considerably faster than Python 2 ever was.
That had been not so for many years, I'd say until later 2017.

Also in a better world Py3 branch would have been abandoned and improvements ported into Py2, resulting in even more speedup.

PHP (amazingly) did the right thing by abandoning PHP6 and instead focusing on improving existing version.

Revisiting PEP 394

anselm — Tue, 05 Mar 2019 23:52:07 +0000

The thing is, Py2->3 porting does not give you any advantages.

These days if you want up-to-date third-party library support then Python 3 is pretty much required. For example, you can't use current Django with Python 2 (the last version of Django to support Python 2 is on “extended support” – fixes for security and data-loss bugs only – until April 2020 or so), and many other important projects have similarly committed to supporting Python 3 only going forward.

These projects don't do this just to spite Python 2 users. Not having to support a codebase that must run on both Python 2 and 3 makes life a lot easier for them, and lets them concentrate on producing better Python 3 code.

And for a long time it had been quite often slower than Py2 (it's _mostly_ fixed now).

Not just “fixed”. In various important areas, Python 3 is now considerably faster than Python 2 ever was.

Revisiting PEP 394

Cyberax — Tue, 05 Mar 2019 19:45:50 +0000

> What I don't agree with is the idea that we should never break compatibility. Of course it's very costly and should be done very rarely and very carefully. Having to port code or to keep an old interpreter/compiler around is no fun. But at some point, it becomes even less fun to be dragging along old cruft, making the language and tools self-defeatingly complex for the sake of backward-compatibility (hello, C and C++ !).
The thing is, Py2->3 porting does not give you any advantages. Py3 code is not safer or more concise, it doesn't provide you any new powerful abstractions. And for a long time it had been quite often slower than Py2 (it's _mostly_ fixed now).

Revisiting PEP 394

moltonel — Tue, 05 Mar 2019 15:10:59 +0000

As I was writing that post I knew that because latest gcc can still compile K&R, it's not the same situation as Python. But I didn't switch to a more comparable language, because the post felt funnyer with C and/or because I was lazy.

Since you mention PHP, it is a "good" example of compatibility breaking between versions. Some language features were security hazards and were rightfully deprecated and removed, breaking older scripts. In Python, the string vs bytes is a good example of something that really needed to change in the language, justifying a compatibility break.

You can certainly argue that the switch should have been more progressive. Having to break one thing shouldn't be seen as an opportunity to break 10 other things. Some things like print function could be imported from future. PHP handled this via a config file, feature by feature. The big question is if that would have made the py2 -> py3 transition faster, but nobody has an answer to that. The python devs were clearly surprised that the transition took so much time.

What I don't agree with is the idea that we should never break compatibility. Of course it's very costly and should be done very rarely and very carefully. Having to port code or to keep an old interpreter/compiler around is no fun. But at some point, it becomes even less fun to be dragging along old cruft, making the language and tools self-defeatingly complex for the sake of backward-compatibility (hello, C and C++ !).

To put things back in perspective with the article, the choice of default python version might cause breakages but those are trivial to fix, and that choice arguably belongs to the system administrator rather than language devs anyway.

Revisiting PEP 394

mirabilos — Tue, 05 Mar 2019 00:47:08 +0000

I get your point, and it is a good argument, brought over humorously.

I’m not buying it, though.

Whatever is installed as cc on modern systems (usually GCC or clang) is normally still able to compile K&R C, or at least the very first ANSI C programs, modulo the newly-informed UB rules. (I literally have the 1970s nroff in the source tree of MirBSD, ugly as hell but compiles.)

On the other hand, py3k is a completely different programming language from Python (2) and *deliberately* incompatible. (Upstream agrees, as they say it was, in hindsight, not a good idea, and that they won’t do that again.)

So, while we have C89, C99, C11 as versions of C, and PHP 4.x, 5.x, 7.x as versions of PHP, we have Python 2.x and Python3 3.x. (I first saw Python when it was at version 2.1, for the BitTorrent official client, back then still OSS, so I don’t know enough to comment on versions before that. But Python 2.1 stuff is still usable, with very small changes, under 2.5, so it does still work.)

Switching from Python to py3k also often means changing your dependencies, at the very least the Debian packages are named differently, but people sometimes took the chance to reorg. C libraries are usually usable from all versions of the compilers on that given platform, and C++ libraries occasionally break ABI but are still source-level compatible.

I hope this explains well enough why I believe these not comparable.

(Funnily enough, Perl has a similar problem…)

Revisiting PEP 394

moltonel — Mon, 04 Mar 2019 22:26:37 +0000

Considering how many books have been written for K&R C, and the long time distributions are supported (which was mentioned), it is my strong opinion that
“cc” should NEVER compile using ANSI C, or C89, or C11, or C18.

Instead, source code as well as books ought to make clear that they target C18 instead of C (K&R). This also makes it easier to select a suitable {book,script} when you have multiple, by glancing at the compile command (of an example in the book, or of the Makefile).

Jokes asside (sorry), I'm gad that I can use "C" or "Python" as a generic term, and can usually expect an unversioned executable name to correspond to a recent version of the project.

Revisiting PEP 394

moltonel — Mon, 04 Mar 2019 22:08:49 +0000

The compatibillity issue is the same, whether you feel it's the distro's fault or the script's. Is your script buggy because it doesn't run on my system, or is my system buggy because it's different from yours, or should we not assume that a program written for a system ought to work on another one ? The many valid answers are somewhere in-between.

PEP 394 took an idealistic stance when it specified that "python" should point to "python2", but the world did not follow that ideal. Some moved sooner than others, and today is the PEP authors's turn to change their mind. The demise of "python is always python2" was inevitable (noone wants to keep version numbers in the name forever just because an older version is incompatible), and the original PEP should have prepared us better. Hindsight is 20/20.

It's whishfull thinking that your script from 30 years ago still run bug-free on a modern system. My ipchains scripts are useless. My php scripts attempt to use insecure APIs. My CLI flags on GNU utils are now no-ops. My C looks for the wrong headers. The sad reallity is that code bitrots and needs to be maintained. If the only maintenance needed is specifying an interpreter version, it's not too bad.

Revisiting PEP 394

anton — Mon, 04 Mar 2019 18:25:02 +0000

Decisions by "a few distros" are only relevant to people who use them and who want to be compatible with them. They certainly don't make previously existing scripts buggy. Some will see these distros as being "bleeding edge", others as "buggy" (but that's just two different names for the same attitude).

Previously existing scripts should continue to work, so the unversioned python should point to the latest compatible installed version, i.e., the latest python2. PEP 394 got that right.

BTW, I am not a Python user, but the cavalier attitude to backwards compatibility that you espouse, and that is rampant in Linux distributions in recent years is really worrying. One of the nice things about Linux (in contrast to Windows) is that Unix scripts that I have started 30 years ago still work. But maybe for not much longer.

Revisiting PEP 394

mirabilos — Sun, 03 Mar 2019 22:51:41 +0000

Considering how many books have been written for Python (2), and the long time distributions are supported (which was mentioned), it is my strong opinion that

“python” should NEVER point to Python 3

Instead, scripts as well as books ought to make clear that they target py3k instead of Python (2). This also makes it easier to select a suitable {book,script} when you have multiple, by glancing at the shebang (of an example in the book, or of the script).

I’m glad Debian is going to implement this.

Revisiting PEP 394

intgr — Sat, 02 Mar 2019 22:35:34 +0000

> with the eventual Python 4, whether that's compatible with Python 3 or not

Python developers have stated on the record that breaking compatibility so harshly with Python 3 was a huge mistake and will not be repeated. If there will be a Python 4, it won't be the same kind of nightmare that Python 3 was, but will hopefully follow the usual practice of __future__ flags and deprecations announced well in advance.

> Allow scripts to declare the Python versions they're compatible with

That's already somewhat covered by the __future__ module: https://docs.python.org/3.8/library/__future__.html

Revisiting PEP 394

jani — Fri, 01 Mar 2019 08:49:33 +0000

Oh, obviously scripts could still use specific python3 or python4 shebangs, but would use plain python shebang with python_requires if they are compatible with multiple versions.

Revisiting PEP 394

jani — Fri, 01 Mar 2019 08:44:31 +0000

For the plain python shebang to be forward compatible with the eventual Python 4, whether that's compatible with Python 3 or not, they'll need to provide a mechanism for the scripts to specify which Python versions they're compatible with. Simply switching python to point at python3 will generate another problem with Python 4, and especially so if it breaks compatibility with Python 3. If the plain python shebang sticks to Python 2, what shebang do you add to scripts that are compatible with both Python 3 and 4?

So here's an idea: Allow scripts to declare the Python versions they're compatible with using a python_requires special comment near the top of the file. The plain python shebang would be a launcher that looks at the comment, and runs the latest compatible Python version that's available, or falls back to a baseline Python version if there's no python_requires. I think the baseline could be Python 2.

PEP263 (https://www.python.org/dev/peps/pep-0263/) defines a special comment for encoding, this would be similar.

PEP440 (https://www.python.org/dev/peps/pep-0440/) defines the version identification and dependency specification.

The Python packaging user guide (https://packaging.python.org/guides/distributing-packages...) defines the python_requires for packaging.

Revisiting PEP 394

flussence — Fri, 01 Mar 2019 01:15:48 +0000

>realistically it'll be around for longer (see: Perl5).
Perl 5 has been markedly improving as of late (since v24) in keeping its EOL promises. The current release removed several things that were marked deprecated back in the 20th century; v30 is getting rid of a bunch of line-noise variables ($*, $[, $#). Simply dumping "use 5.008" into a file is no longer a magic ward against having maintainable software.

Revisiting PEP 394

jccleaver — Fri, 01 Mar 2019 00:13:33 +0000

The terrible thing is the unpredictability. Sure, it's predictable for the admin -- until they have to install python v2 for some reason and everything breaks.

As the post indicates, this is an awkward time for the transition. The fact remains that the Python folks handled this whole thing horribly and the blame for the mess resides on them.

IMO, for the time being, "/usr/bin/python" SHOULD be a reference to python v2, and python3 scripts SHOULD reference "/usr/bin/python3" in their shebangs.

While "bleeding edge" distros might want to get ahead of this, that's not a good reason for the upstream recommendations to not reflect reality, which is that large chunks of the userbase don't plan on getting rid of python2 any time soon due to the existing scripts. The perl5->perl advice on shebangs was proffed only after perl4 was LONG dead, though it was helped by the fact that there weren't that many incompatibilities (and there were conversion scripts that could handle most of them). IMO the actual python *userbase* is not there yet.

Revisiting PEP 394

JFlorian — Thu, 28 Feb 2019 16:57:23 +0000

Rule #2 of PEP 20 seems awfully relevant here. For those who don't remember:

$ python
>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
...

Revisiting PEP 394

cpitrat — Thu, 28 Feb 2019 15:50:04 +0000

So pointing python to python3 will do the job, unless those scripts were compatible.

Revisiting PEP 394

lkundrak — Thu, 28 Feb 2019 15:24:19 +0000

> you change it to a modern (and maintained) implementation

...of something else

Revisiting PEP 394

NRArnot — Thu, 28 Feb 2019 13:51:55 +0000

Why not replace the un-versioned python command with a file-analyzer that tries to do the right thing?

1. Output a warning message to stderr that the un-versioned python command is strongly deprecated.
2. Scan the script to identify any hints as to which python version is required. For example, a print statement without brackets requires python 2, an f-string requires python 3, any type hint strongly implies python 3, ...
3. Output another warning saying what it's going to try next
4. Dispatch the script to python3, unless python2 was clearly required, in which case...
5. Dispatch to python2 if it exists on the system or explain the problem if it does not.

This will work most of the time, and the warning messages (whether or not it does work) ought to nag the script maintainers to fix their shebangs.

If invoked without a script (interactive), tell the user to choose between python2 and python3 and quit.
This isn't something that has to be perfect. A 90% solution is better than a 0% non-solution.

Revisiting PEP 394

moltonel — Thu, 28 Feb 2019 10:31:55 +0000

A few distros that have either switched "python" or made it configurable for many years now, so any script that uses an unversioned bangline but isn't compatible with both py2 and py3 is buggy, in that it's not going to work on different distros. The unversioned python should point to the latest installed version, as would be expected of any other program.

Fixing banglines is trivial, only the diagnostic-to-bugreport-to-new-package bureaucracy takes a bit of time. After so many years, I'd expect that most packaged python2-only scripts have been fixed, and only in-house packages remain. It shouldn't be that hard to write a script to find and report/fix such scripts.

I'm unsympathetic to the "it'll break my setup" argument when the fix is so simple and has been needed for so many years. The python community has been doing extra work to support a legacy version, waiting for people to switch for surprisingly many years. It's time to give them a rest.

Revisiting PEP 394

mcharsley — Thu, 28 Feb 2019 09:57:01 +0000

Didn't we have an almost identical problem way back when python 2 came out? I have vague memories of some distribution, probably RedHat, having /usr/bin/python pointing to python 1.5 because they'd got a bunch of admin scripts that weren't yet compatible with python 2

Revisiting PEP 394

Cyberax — Thu, 28 Feb 2019 09:43:03 +0000

No. A careless script writer will just put "/usr/bin/python" and it will work. Then somebody installs Py2 and a completely unrelated package might break. Bonus points if it breaks in a rarely-used code path.

This is pretty much THE worst possible solution.

Revisiting PEP 394

lobachevsky — Thu, 28 Feb 2019 09:18:20 +0000

Arch Linux changed their python to be python3 years ago and is basically the reason for this PEP to exist. Arch is known for not patching upstream packages if possible. A lot of shebang fixeshave found their way upstream and even before that the world didn't burn down with that change and it's been a few years now.

I agree that it's a disservice to have no unversioned python available and think that the stance to never point the symlink away from python2 quite backwards.

Revisiting PEP 394

karkhaz — Thu, 28 Feb 2019 09:11:42 +0000

> With the uptake of Python 3 (and the imminent end of life for Python 2.7), there is a question of which version of Python a user should get when they type "python" at the command line or have it as part of a shebang ("#!") line in a script

IMO these are two separate questions, and I don't see that acknowledged in the PEP. This is because the implications of the default behaviour are different in each case. When typing 'python' at the command line, you're immediately greeted with the version number that's running, and you can just <Ctrl-D> if it's not the one you expected. Scripts, on the other hand, can be executed non-interactively in the background and might thus break people's setups in non-obvious ways if they fail.

So it seems to me that the sensible behavior is to make python point to the latest version of python when invoked on the command line, but python in shebang lines should continue to point to python2 forever. And I say this as an Arch Linux user, whose python has pointed to python3 since the beginning, and I'm perfectly happy with this---but acknowledge that it's untenable for the more mainstream distros.

Revisiting PEP 394

mjthayer — Thu, 28 Feb 2019 08:10:58 +0000

A script for python3 which does not support python2 should explicitly request /usr/bin/python3. If it does not it will not work today in most set-ups.

'python' should be for interactive use

marcel.oliver — Thu, 28 Feb 2019 07:55:46 +0000

I can't wait until my distro (Fedora) points python to python3. It's a constant annoyance to get the wrong Python, or wrong ipython via tab completion in the shell (if only they had named it 3python), then it would be half a problem. Scripts can be fixed, and presumably one should use explicit versioning anyway.

Yes, I could define my own alias, but I am also teaching various Scientific Computing classes, so changing defaults would seriously confuse students.

Unfortunately, for students on Linux, I must still check which version of Python they are actually running, which is erratic in practice, and if it's 2.7, debug their scripts for floored-division errors. Just happened two days ago, again.

I will probably have 2.7 around for as long as that's just a dnf install away, due to long-forgotten legacy scripts, but having the default invocation point to a dying version is a very poor user interface. I notice that Matplotlib in its latest version is Python 3 only, which tells me that it's really time to get off Python 2 in my domain.

Revisiting PEP 394

Cyberax — Thu, 28 Feb 2019 07:34:42 +0000

It's even worse. A script for Py3 can suddenly break if Py2 is simply installed.

Revisiting PEP 394

mjthayer — Thu, 28 Feb 2019 07:23:42 +0000

What is so terrible about /usr/bin/python pointing to python2 if it is installed and python3 if it is not? I would expect a python3-only script to explicitly specify /usr/bin/python3 for very practical reasons, and any script which specified /usr/bin/python to work with python2. So someone who needs to run scripts which are not python3-compatible installs python2 and everything works. And someone who does not does not and everything works.