[Python-Dev] PEP 394: Allow the `python` command to not be installed (and other minor edits)

[Petr Viktorin]

Hello,
After discussion on the [Pull Request], my update to PEP 394 changed 
scope somewhat. The new major changes are:

- The `python` command may not exist at all in some cases (see the PEP 
for details)
- The paragraph about the anticipated future where python points to 
Python 3 is removed. (We'd rather see a future where `python` doesn't 
exist and one always has to specify `python2` or `python3`.)
- The PEP now explicitly says that in an active venv, python means that 
venv's interpreter. (Some view this as a design mistake, but one not 
worth reverting now.)

There are also other edits and clarifications.

Thanks for everyone involved, especially Guido for pitching in with the 
intended direction -- which was not clear from (or is genuinely 
different from) the 7-year-old PEP!

I'll keep the PR open for a day or so, in case someone still wants to 
comment.

[Pull Request]: https://github.com/python/peps/pull/630


On 04/26/18 19:21, Ben Finney wrote:
> Petr Viktorin <encukou at gmail.com> writes:
> 
>> In Fedora, I found that PEP 394's strict recommendation that `python`
>> points to `python2` is holding us back.
> 
> I have read the message, but I don't see how you draw the link that PEP
> 394 is holding you back.
> 
>> The problems are:
>> - For developers that are not following the language's development,
>> the fact that `python` invokes `python2` sends a strong signal that 2
>> is somehow the preferred version, and it's OK to start new projects in
>> it.
> 
> I agree with the statement you make later in the message:
> 
>> […] we feel that the only way to *enforce* that guidelines is to
>> provide environments where the `python` command does not work (unless
>> explicitly installed).
> 
> Yes. The ‘python’ command is confusing, for the reasons you say. There
> should be ‘python2’ and ‘python3’ commands for Python 2 and Python 3
> respectively, and no ‘python’ command should be installed by the
> operating system.
> 
> The fact that ‘/usr/bin/python’ exists is an historical accident, and I
> agree with the proposal you state: the best way to correct the confusion
> is to bar the confusing command from being installed by packages.
> 
>> - Users and sysadmins that *do* want to “live in the future” are
>> switching the symlink to `python3` themselves. We would like to give
>> them a supported, documented way to do so -- and make surer they're
>> aware of the caveats.
> 
> The supported, documented way to add a command pointing to a different
> command already exists, and there is no need to make a Python-specific
> special case.
> 
> Users who want to make a ‘python’ alias can do so in their shell; this
> is supported and documented.
> 
> Users who want to add a new command file can add a suitable directory
> (e.g. ‘$HOME/bin’) to their ‘PATH’ variable, and put a symlink in there
> named ‘python’. This is supported and documented.
> 
> Sysadmins who want to create a system-wide command ‘python’ can put a
> symlink at ‘/usr/local/bin/python’. This is supported and documented.
> 
> I disagree with making some special-case extra way; that would be both
> cunfusing and superfluous.
> 
>> - The `python` command is still not available out-of-the box on macOS,
>> so it didn't completely live up to the expectation of being the
>> cross-platform way to launch 2/3 source compatile scripts.
> 
> That is one of the minor ways which macOS fails to conform to
> community-agreed conventions. We should not let that intransigence
> distort our discussion of best practices.
> 
>> To help solve these, I would like to relax recommendations on the Unix
>> ``python -> python2`` symlink in these cases:
> 
> For the above reasons, I disagree that PEP 394 is limiting what you want
> to do on free-software operating systems.
> 
> For non-free operating systems, I don't think the already-discussed PEP
> 394 should be weakened if the operating system vendor fails to conform.
> 
>> - Users and administrators can, by a deliberate action, change
>> ``python`` to invoke Python 3.
> 
> Yes. That is well-known and long-standardised on Unix operating systems,
> and is much more broadly understood than any Python-specific special
> case would be. So I don't see how anyone is being held back.
> 
> I trust that PEP 394 will not be weakened in its effect, and I wish you
> well with using the already-supported, already-documented, PEP-394
> compatible means to add local customisations for a ‘python’ command.
>