[Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

[Petr Viktorin]

On 2/26/19 6:54 PM, Barry Warsaw wrote:
>> There haven't been many new ideas since this summary – mostly it was explaining and re-hashing what's been mentioned before.
> 
> Thanks for the summary Petr.
> 
> Here’s another way to think about the problem.  I know Nick and I have talked about this before, but I don’t think any distros have actually done this, though I’ve been out of that business a while now so correct me if I’m wrong.
> 
> I see this question as having several parts, and the conflation of them is part of the reason why the unversioned `python` command is so problematic.  Python is used for:
> 
> * OS functionality
> * to run applications that aren’t critical to the OS but are delivered on the OS
> * as the entry point to the interactive interpreter
> * to run applications written and deployed on the OS but completely outside of it
> 
> Which `python` are we trying to change?  All of them?
> 
> For OS functionality, there should probably be a separate command not conflated with /usr/bin/python.  The OS can make any adjustments it needs, calling it `spython` (as I think Nick once suggested), or whatever.  Nobody but OS maintainers cares what this is called or what version of Python it exposes.

Yup. RHEL 8 actually has exactly that. (It's called 
/usr/libexec/platform-python; please don't use it!)
Fedora (and most other distros) makes this the same as the interpreter 
for other packaged software. For Fedora the main reason is that don't 
want to maintain two full separate Python stacks.

> I strongly believe that (eventually) the interactive interpreter command should be /usr/bin/python and that this should point to Python 3, since this provides the best experience for beginners, dabblers, etc.

+1

> So what about the other two use cases?  Well, for applications packages within the OS but aren’t critical to it, I think they should always use the versioned shebang, never the unversioned shebang.  Distros can control this, so that transition should be easier.

+1

> The tricky part then seems to me what to do for 3rd parties which are using the distro Python in their shebangs?  Nobody sees their code but them, and changing the shebang out from under them could cause their code to break.  But don’t they already take lots of precautions and planning for any OS upgrade?  Changing the shebang for Python 2 would be just one of the things they’d have to worry about in an OS upgrade.

Also, things will break for them anyway, it's just a matter of time. 
Python 2 *is* going away, eventually. (Right?)
I don't think we're doing that many people a favor by keeping 
/usr/bin/python → python2 around. Instead, we're *hiding* the problem 
from them. Too many people think python2 is still the "default".

Making /usr/bin/python be missing for some time, rather than pointing it 
to python3 now, is the more explicit way to do the transition.

> I don’t know whether this analysis is complete or correct, but perhaps it helps inform a way forward on PEP 394.

I have two very different questions in mind for moving this forward.

Who gets to decide on PEP 394 changes?
Since so many people on python-dev are in agreement, where do I go for 
opposing voices?