[Linux-SIG] Revisit of PEP 394 -- The "python" Command on Unix-Like Systems

[Barry Warsaw]

Thanks for getting this discussion going again.  The more I talk to people about the upcoming EOL for Python 2.7, the more I realize that while 2.5 years *seems* like a long way away, it’ll be here sooner that many are planning for.  “Winter is coming” is a phrase that pops into my mind (although maybe it should be Summer, as I think Python 3 invokes a lot more optimism than the White Walkers. :)

A couple of top-line points first:

* As I mentioned to Nick off-list, I think we should amend PEP 394 rather than supersede it.  It’s widely cited as *the* upstream policy on the matter, so I think we’ll get more bang for the buck, and less overall confusion, by updating it rather than replacing it.

* My personal preferences have been evolving on this subject too, so I won’t claim to represent the Debian ecosystem here.  That’s a discussion to be had over in that forum.  For now, take all of the following as my personal opinion.

> On Jul 25, 2017, at 08:02, Charalampos Stratakis <cstratak at redhat.com> wrote:
> 
> tl;dr Let's make sure that PEP 394 says "/usr/bin/python should be Python 3 by early 2020”

I think that’s just a bit too early.  Consider the timeline.  Guido has proclaimed[*] that Python 2.7 will EOL at Pycon 2020, which will likely be in the May-June timeframe.  I think any changes we make should either be timed to coincide with that event, or happen in the latter part of 2020.  It’s also very likely that Python 2.7 support won’t abruptly end on that date, but instead will continue with some level of security-only, source-only releases for a while after.  For the moment though, let’s not quibble on the timing.

[*] At the Language Summit 2017; sorry no reference handy atm.

> Various upstream Python projects have also started down to the path to completely dropping Python 2 support in order to start taking full advantage
> of Python 3 only features: http://www.python3statement.org/

Oh nice!  I wasn’t aware of this site, and will likely sign up to it soon.  I’ve already mostly dropped Python 2 support for most of my personal projects, and of course GNU Mailman 3 Core has been Python 3-only for a while. (Some of the other components are not quite there yet, but we’re committed to it.  Mailman 2 will likely never get ported.  I suspect that fate will be shared by many projects, alas.)

> In Fedora, we'd like to change /usr/bin/python to point to Python 3 by 2020 (when PEP 404 kicks in). However, we'd rather not do it without upstream's
> support in PEP 394. Hence we would like to drive the change of PEP 394 to either say that /usr/bin/python should point to Python 3, or to say it is up
> to the distribution maintainers. (And we would prefer the first option, so that the situation may eventually become consistent.)

Consistency across the Python ecosystem should be a top concern.  The Python 3 transition has been a tumultuous one, and we’ve had successes and challenges.  Overall, I think we’re in a good place right now, so let’s make sure we handle the end of the transition as well as possible!  People may argue about whether such-and-such a decision is right or wrong, but uncertainty is much worse.

> The message we want to send is: "everything that can be ported to Python 3 should be ported, and everything that can run on Python 3 should run on it.”

+1

> However, having /usr/bin/python point to Python 2 is continuing the concrete mindset for Linux users that "the default" version of Python is still Python 2.
> Those mixed signals are especially problematic with maintainers that aren't familiar with the Python ecosystem (e.g. they only use a Python-based buildsystem).

IMHO, the reason why this is so is because `python` (at the prompt, a.k.a. typically /usr/bin/python) is the CLI API for *users*.  It’s what they’re taught to type at the command line to run their scripts or to start the interpreter to play with things.

PEP 394 already recommends `python2` and `python3` in the shebang line for distro-provided executables.  I think we turn some SHOULDs into MUSTs so that any PEP-394 compliant *nix distro will be required to follow the same rules.  Further, I’d add that PEP 394-compliant distros MUST NOT put /usr/bin/python in shebangs.

(PEP 394 does not talk about `/usr/bin/env python` which is often used by developers, although highly discouraged for distro-provided scripts, at least in Debian.  If we want to add a note about this, I think we make it clear that this usage relies solely on the user’s own $PATH environment, and therefore lies outside the scope of the PEP.)

I’d like to discourage the use of naming schemes like `idle2`, `pydoc2`, etc.  That’s a problematic approach, for which -m invocation is much more predictable, albeit less convenient.  We still don’t have a good solution for that, although many have been discussed.  That’s probably outside the scope of PEP 394 too.

Lastly, we come to what /usr/bin/python points to, and that’s always been the sticking point.  There are two use cases.

* When people type that at the command line, which version of Python do they get?
* When people use that in their own third-party (i.e. not distro-provided) scripts, what version of Python do they get?

So, it’s a UI/UX problem now :)

I would personally like to say /usr/bin/python will always point to python3 after such-and-such a date, although as I’ve said above, my timing would put that to later in 2020.  However, I think we need to allow distributions to make their own decisions on that timing.  Some may choose to never make it, others may be proactive.

There are two ways to go here.  Either we can make it a MUST to point /usr/bin/python to python3, and just label any distro that decides otherwise as “non-PEP-394-compliant”, or we make the choice more lax (possibly SHOULD, possibly MAY) and allow leeway for otherwise in-compliance distros.  I suspect there will be some in Debian that will argue for the latter, and they will make good points.  OTOH, I think we’re well past the tipping point, and will face the cliff pretty darn soon.  I haven’t completely made my own mind up on this point.  In the meantime, I think we can make a lot of progress on PEP 394 as I’ve outlined above.

Cheers,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/linux-sig/attachments/20170731/e8c3f19f/attachment.sig>