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

[Petr Viktorin]

On 07/31/2017 04:25 PM, Barry Warsaw wrote:
[...]
>> 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.

+1
Ah, yes, this is missing from the "PEP 548" pull request.

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

+1

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

I think that ship has sailed. The unversioned names should switch along 
with /usr/bin/python, and the versioned ones should be allowed to die 
along with /usr/bin/python[23]. Improving the -m situation is out of scope.

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

The other recommendations proposed here are designed so they can be 
implemented right now, with no bad side effects, but switching 
/usr/bin/python will break things. I think here it's good to leave the 
timing up to distros, and to suggest that the distros allow users to 
override their decisions.