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

[Nick Coghlan]

On 28 April 2018 at 01:37, Petr Viktorin <encukou at gmail.com> wrote:

> 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`.)
>

That isn't currently *my* desired future, as I don't want to see a python3
to python4 naming transition at any point, I want a transition from python3
back to an unqualified name to accurately reflect the change in version
management philosophy resulting from the extended Python 3 migration. (And
then "python3" would linger solely as a backwards compatibility remnant,
even if it referred to python 4+, or a switch to some kind of CalVer based
versioning scheme)

However, it may be possible to solve two problems at once here, as one of
the issues we have in writing cross-platform instructions for both Windows
and *nix systems is that "python" isn't guaranteed to be on the Windows
path, but the "py" launcher *is*. This means the most robust tooling
invocations on Windows are of the form "py -m pip ...", since they don't
care about how your system PATH is configured. Getting not only "python",
but also scripts installed with "py -m pip install --user..." to be
reliably on the PATH is an arcane problem with assorted complications
stemming from the differences between per-machine and per-user
installations of Windows applications, and the "py -m module ..." approach
avoids that mess entirely (as long as the tools of interest correctly
support invocation via "-m").

The downside of those instructions is that it means we have a platform
split where, depending on how your system is setup, which version of Python
you're using, and whether or not you're running in a virtual environment,
you need to invoke Python from the command line as one of:

- python
- python3
- py

(more details at
https://github.com/pypa/python-packaging-user-guide/issues/396 )

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!
>

It's a change, and not one that's been explicitly discussed with the
current authors of the PEP yet (although I do see that Barry has chimed in
on the PR).

I think it's a reasonable way for us to go, *if* it's accompanied by an
explicit decision that we want to drive cross-platform convergence around
"py" as the convention for unqualified version independent access to a
Python interpreter (regardless of whether or not a virtual environment is
active or not)

The key missing piece for doing that would be to define how we'd want a
`py` launcher to work on *nix systems, and then provide that as part of
CPython 3.8+ (and potentially backport it to a 3.7x maintenance release).

Cheers,
Nick.

P.S. Note that on Windows, `py` always refers specifically to the launcher
(it doesn't get shadowed in virtual environments), but the launcher itself
is virtual environment aware (see https://www.python.org/dev/peps/pep-0486/
for details).

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180428/6a1be4ff/attachment.html>