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

Gregory P. Smith greg at krypto.org
Tue Feb 26 16:20:30 EST 2019

On Tue, Feb 26, 2019 at 9:55 AM Barry Warsaw <barry at python.org> 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.
> 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.
> 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.
> 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.

A feature that *I* find missing from posix-y OSes that support #! lines is
an ability to restrict what can use a given interpreter.

For an OS distro provided interpreter, being able to restrict its use to
only OS distro provided software would be ideal (so ideal that people who
haven't learned the hard distro maintenance lessons may hate me for it).

Such a restriction could be implemented within the interpreter itself. For
example: Say that only this set of fully qualified path whitelisted .py
files are allowed to invoke it, with no interactive, stdin, or command line
"-c" use allowed.  I'm not aware of anyone actually having done that.  It's
hard to see how to do that in a *maintainable* manner that people using
many distros wouldn't just naively work around by adding themselves to the
whitelist rather than providing their own interpreter for their own
software stack.  It feels more doable without workarounds for something
like macOS or any other distro wholly controlled and maintained as a single
set of software rather than a widely varying packages.

Solving that is way outside the scope of PEP 394.  Just food for thought
that I'd like to leave as an earworm for the future for distro minded
folks.  I some people to hate this idea.


> I don’t know whether this analysis is complete or correct, but perhaps it
> helps inform a way forward on PEP 394.
> Cheers,
> -Barry
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190226/01a57c41/attachment-0001.html>

More information about the Python-Dev mailing list