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

[Barry Warsaw]

On Jul 31, 2017, at 19:40, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> On 1 August 2017 at 03:47, Barry Warsaw <barry at python.org> wrote:
>> On Jul 26, 2017, at 00:29, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> 
>>> At the PEP 394 level, what I'd personally like to see us do is to
>>> split the "Recommendations" section into two separate sections:
>>> "Python User Recommendations" and "Platform Publisher Recommendations”
>> 
>> I’d like to keep PEP 394 as short and proscriptive as possible.  I’ve always read PEP 394 as being aimed at “platform publisher recommendations”, i.e. distributions who provide.  I think a user guide would make a good companion (i.e. separate) PEP.
> 
> Until yesterday I would have said the same thing regarding the current
> contents of PEP 394, but a surprisingly large number of the points in
> the new user recommendations section actually came from the current
> text of PEP 394 - they're down at the end of the recommendations
> section, and when they were all in one list, it was easy to miss that
> we'd crossed over from "Advice to platform publishers" into "Advice
> for platform users”.

After having reviewed the proposed PEP 548 PR, I still think we can keep 394 and target it specifically to platform vendors.

> - we declare "/usr/bin/env python" and other environment aware
> invocations as already being effectively addressed, thanks to venv,
> environment modules, conda, and other existing PATH based solutions
> that change the interactive meaning of "python"
> - by some suitable mechanism, we offer 3 different configurations for
> the absolute "/usr/bin/python" path: symlink to /usr/bin/python2,
> symlink to /usr/bin/python3, and "Not configured yet, here's how to
> select your default interpreter" (as a matter of UX, I'm beginning to
> think we'll need to make the last one an actual installable script in
> its own right, as the default interpreter not found error from the
> shebang handler isn't particularly informative)

Another option is to make /usr/bin/python not actually *the* Python interpreter, but instead a wrapper that does $magic to get the right version.  Several options have been bandied about over the years, and IIRC, Windows does something like this.  Maybe it’s switchable based on a config file (both system and user overridable), or maybe there’s some other way.  It won’t help start-up time <wink> but it could provide a better user experience.

> In that light, it may make sense to more explicitly focus the PEP 394
> recommendations on *absolute* invocations that *don't* rely on PATH.

+1

-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/20170801/1b051277/attachment.sig>