The Python 3.4b2 installer for Windows does not install a "pip.exe" wrapper when the default options are selected. Only the "pip3.exe" and "pip3.4.exe" commands are provided.

The documentation for ensurepip makes it clear that this is the default behaviour, but there is no comment in either the PEP or in "Python Setup and Usage" stating that this is what happens. Also, I imagine that people will expect a "pip" command to be available by default, so an explanation of *why* only the versioned commands are installed should be added.

(It may be that having the unversioned command as well is actually the correct thing to do, on Windows if not on Unix - I can't recall the details of the discussion. If so, maybe the correct thing to do is to change the Windows installer behaviour).

This is deliberate - the unversioned command is only installed into virtual
environments.

Fair enough. Can the justification be recorded somewhere, please? It's inconsistent with most other Python commands on Windows. (I don't recall what the justification was, and can't come up with a search that locates the discussion thread).

I'm not sure we specifically considered the Windows case - we were avoiding
the name collision with pip for Python 2 on POSIX systems.

The decision on which names to install is actually made in pip itself,
though, ensurepip just indicates what kind of install it is.

It would not be impossible for the ensurepip call in the Windows installer to set the --default-pip flag, if that gives a better user experience on Windows.

I'm not wedded to either answer myself, but given that versioned executable names are uncommon on Windows, I can easily imagine a series of bug reports saying "I asked for pip to be installed, and it's not there". Making a deliberate decision one way or the other and documenting it seems like the minimum reasonable approach.

This is still the case in the 3.4rc0 Windows installer. Could we get something definite for 3.4 final? It may be too late for that to be anything other than documenting that the command "pip" is not available, but given that most 3rd party documents use "pip" as the command, it probably is worth being explicit.

Oops, missed this already existed when I created issue 20568. I currently plan to have this fixed for rc2 on the 23rd.