(original) (raw)
On 28 April 2018 at 01:37, Petr Viktorin <encukou@gmail.com> wrote:
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)
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\`.)
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
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).
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).