Petr Viktorin <encu...@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.
