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

Nick Coghlan ncoghlan at gmail.com
Fri Apr 27 21:23:13 EDT 2018

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:

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

More information about the Python-Dev mailing list