Would something like this be helpful?
(`python -m pip` seems to work fine after `conda install pip` after a miniconda install)


#!/usr/bin/env python
Something like this as e.g site.discover
(for use as ``python -m site.discover``)
could be helpful for explaining and diagnosing multiple pythons and pips

import os
import re
from distutils.spawn import find_executable
from subprocess import check_output, STDOUT
import collections

def discover(path=None, printsite=False, uniques=True):
    Find all ``python*`` and ``pip*`` executables and their version strings
    within ``os.environ['PATH']``

        path (str): os.pathsep-delimited path str
            (defaults to ``os.environ['PATH']``)
        printsite (bool): call ``<python> -m site``
            with each found python binary
        uniques (bool): print uniques according to ``os.realpath`` at the end

    if path is None:
        path = os.environ['PATH']
    rgx = re.compile(r'(python|pip)\-?(\d?\.?\d?)$')
    uniques = collections.OrderedDict()
    for directory in path.split(os.pathsep):
        paths = sorted(
            ((match.group(0), match.group(2)) for match in
                (rgx.match(name) for name in os.listdir(directory))
             if match),
            key=lambda x: x[::-1],
        print(u'# %s' % directory)
        for (name, ver) in paths:
            pathjoined = os.path.join(directory, name)
            binpath = find_executable(pathjoined, directory)
            realpath = os.path.realpath(binpath)
            if binpath is None:
                if os.path.exists(pathjoined):
                    if os.path.islink(pathjoined):
                            u"%r is a symlink to %r, which doesn't exist"
                            % (pathjoined, binpath)))
                    # TODO: %r exists but isnt executable
            verstring = check_output((binpath, '-V'),
            uniques.setdefault(realpath, collections.OrderedDict()) \
                .setdefault(binpath, verstring)
            print(u'%-11r %-5r %r' % (name, ver, verstring))
            if printsite and name.startswith('python'):
                sitestring = check_output((binpath, '-m', 'site'))
                lines = (u'> %s' % l for l in sitestring.splitlines())
                for line in lines:
                # TODO: check_output((binpath, '-m', 'pip'))

    # TODO: AND/OR (?) only print uniques at the end
    if uniques:
        print('### UNIQUES')
        for path in uniques:
            print('## %s' % path)
            paths = uniques.get(path)
            for otherpath in sorted(paths):

if __name__ == '__main__':


On Wednesday, November 15, 2017, Steve Dower <steve.dower@python.org> wrote:
On 15Nov2017 0617, Nick Coghlan wrote:
On 15 November 2017 at 22:46, Michel Desmoulin <desmoulinmichel@gmail.com <mailto:desmoulinmichel@gmail.com>> wrote:
    Should I do a PEP with a summary of all the stuff we discussed ?
I think a Windows-specific PEP covering adding PATH updates back to the default installer behaviour, and adding pythonX and pythonX.Y commands would be useful (and Guido would presumably delegate resolving that to Steve Dower as the Windows installer maintainer).

If you write such a PEP, please also research and write up the issues with modifying PATH on Windows (they're largely scattered throughout bugs.p.o and earlier discussions on python-dev).

Once you realise the tradeoff involved in modifying these global settings, you'll either come around to my point of view or be volunteering to take *all* the support questions when they come in :)

The one thing I'd ask is that any such PEP *not* advocate for promoting ther variants as the preferred way of invoking Python on Windows - rather, they should be positioned as a way of making online instructions written for Linux more likely to "just work" for folks on Windows (similar to the utf-8 encoding changes in https://www.python.org/dev/peps/pep-0529/)

Instead, the focus should be on ensuring the "python -m pip install" and "pip install" both work after clicking through the installer without changing any settings, and devising a troubleshooting guide to help folks that are familiar with computers and Python, but perhaps not with Windows, guide folks to a properly working environment.

My preferred solution for this is to rename "py.exe" to "python.exe" (or rather, make a copy of it with the new name), and extend (or more likely, rewrite) the launcher such that:

* if argv[0] == "py.exe", use PEP 514 company/tag resolution to find and launch Python based on first command line argument
* if argv[0] == "python<numeric tag>.exe", find the matching PythonCore/<tag> install (where tag may be a partial match - e.g. "python3.exe" finds the latest PythonCore/3.x)
* else, if argv[0] == "<module><numeric tag>.exe, find the matching PythonCore/<tag> install and launch "-m <module>"

With the launcher behaving like this, we can make as many hard links as we want in its install directory (it only gets installed once, so only needs one PATH entry, and this is C:\Windows for admin installs):
* python.exe
* python2.exe
* python3.exe
* python3.6.exe
* pip.exe
* pip2.exe
* pip3.exe

As well as allowing e.g. "py.exe -anaconda36-64 ..." to reliably locate and run non-Python.org installs.

It needs to be fully specced out, obviously, and we may want to move the all-users install to its own directory to reduce clutter, but part of the reason behind PEP 514 was to enable this sort of launcher. It could even extend to "you don't have this version right now, want to download and install it?"

And finally it should be fairly obvious that this doesn't have to be a core Python tool. It has no reliance on anything in core (that isn't already specified in a PEP) and could be written totally independently. I've tried (weakly) to get work time allocated to this in the past, and if it's genuinely not going to get done unless I do it then I'll try again.

Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/