> 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.
-gps
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@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/greg%40krypto.org