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

Petr Viktorin encukou at gmail.com
Fri Apr 27 11:37:14 EDT 2018

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

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.

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.

More information about the Python-Dev mailing list