I uninstalled python 2.7 and 3.4, then performed a fresh install of 3.5.3.
Running pip with `python -m pip` as per https://docs.python.org/3.5/installing gives the following error:

C:\Python\Python35-32\python.exe: No module named pip.__main__; 'pip' is a package and cannot be directly executed

Installation details:
*  win 7 64 bit.
*  python 3.5.3 32 bit.
*  chose options for pip, tcl/tk/idle, test suite, py launcher, shortcuts, add to env, precompile std lib.
*  installed to non-standard directory.

Please provide the complete traceback. Copy and paste it from the command prompt. Also, include the fully-qualified path for what "python" runs, e.g. run `where python` in the command prompt. Also, include the value of the environment variables PYTHONHOME and PYTHONPATH, e.g. run `echo %PYTHONHOME% & echo %PYTHONPATH%` in the command prompt.

There is no traceback, that is the entirety of the output of the command.

Python bin is C:\Python\Python35-32\python.exe
PYTHONHOME is not set.
PYTHONPATH is C:\python27\lib\site-packages\

I don't know why PYTHONPATH was set.  I cleared it but it made no difference -- same error.

That error looks like __init__.py[c] was left in "C:\python27\lib\site-packages\pip". Just to be sure, since I don't know what you did to clear the value, please run `set PYTHONPATH=` to clear the value for the current shell. Then try `python -m pip`.

When you modify or remove an environment variable using the control panel dialog, it broadcasts a window message that causes Explorer to reload its environment. Generally console applications such as cmd.exe do not own a top-level window (the console window is owned by conhost.exe) and thus cannot see this broadcasted message. To get the updated environment, you have to run a new instance of cmd from Explorer.

Thanks, but I know how to drive a terminal ;)

Your hunch was basically correct though.  I ran again with `python -v -m pip` (see with_pip_dir.txt), and see that python is attempting to import pip from my user directory (C:\Users\amc2\pip).  This is an empty directory, except for an old pip log file from 2.7.

If I rename the directory to something unrelated, `python -m pip` just fails with:

C:\Python\Python35-32\python.exe: No module named pip.

So mystery 1 is solved.

I've definitely selected the pip option in the python installer.  I also repaired the installation, with the pip option selected, and the error still remains.
Where is pip supposed to be located on a win7 install?

pip should be installed in site-packages, which for you is "C:\Python\Python35-32\Lib\site-packages". Try manually running ensurepip to make sure pip is installed:

    python -m ensurepip --verbose --upgrade --default-pip

It's all working fine now, thanks.

If one of the installer/windows guys wants to dig more into why this didn't install properly I'm happy to run things in my environment as necessary.

If you have the 3.5 installation logs in your %TEMP% directory, please zip them up and attach them to this issue.

Install logs attached.
First set from initial install, second set from repair.

The original install failed with the status code STATUS_DLL_NOT_FOUND (0xC0000135), as reported in "Python 3.5.3 (32-bit)_20170217102132_008_pip_JustForMe.log":

    MSI (s) (88:D8) [10:22:59:574]: Executing op: ActionStart(Name=UpdatePip,,)
    MSI (s) (88:D8) [10:22:59:575]: Executing op: CustomActionSchedule(
        Action=UpdatePip,ActionType=1089, Source=BinaryData,Target=CAQuietExec,
        CustomActionData="C:\Python\Python35-32\python.exe" -E -s -m ensurepip -U --default-pip)
    MSI (s) (88:C4) [10:22:59:588]: Invoking remote custom action.
        DLL: C:\Windows\Installer\MSI2C60.tmp,
        Entrypoint: CAQuietExec
    MSI (s) (88:B0) [10:22:59:588]: Generating random cookie.
    MSI (s) (88:B0) [10:22:59:590]: Created Custom Action Server with PID 6212 (0x1844).
    MSI (s) (88:A8) [10:22:59:630]: Running as a service.
    MSI (s) (88:A8) [10:22:59:631]: Hello, I'm your 32bit Impersonated custom action server.
    CAQuietExec:  Error 0xc0000135: Command line returned an error.
    CAQuietExec:  Error 0xc0000135: QuietExec Failed
    CAQuietExec:  Error 0xc0000135: Failed in ExecCommon method
    MSI (s) (88:D8) [10:22:59:658]: Executing op: End(Checksum=0,
        ProgressTotalHDWord=0,ProgressTotalLDWord=287056)
        CustomAction UpdatePip returned actual error code 1603 but will be
        translated to success due to continue marking

Did your system require a reboot for Python 3.5 to work?

From what I can see in "Python 3.5.3 (32-bit)_20170217131555_007_pip_JustForMe.log", it looks like the repair skipped installing pip. 

    MSI (s) (D8:1C) [13:16:31:822]: Skipping action: SetRemovePipCommandLine (condition is false)
    MSI (s) (D8:1C) [13:16:31:822]: Skipping action: SetUpdatePipCommandLine (condition is false)
    MSI (s) (D8:1C) [13:16:31:822]: Skipping action: UpdatePip (condition is false)
    MSI (s) (D8:1C) [13:16:31:822]: Doing action: InstallFinalize
    MSI (s) (D8:1C) [13:16:31:822]: Note: 1: 2205 2:  3: ActionText 
    Action ended 13:16:31: PublishProduct. Return value 1.

Maybe Steve Dower can shed light on why a repair with pip selected didn't try to install pip.

Depending on why the pip install failed, we may still have registered that it was installed. IIRC, we only trigger the install on a state change, which wouldn't happen in repair. That deserves its own bug (though maybe this one will suffice if we figure out the original failure - I haven't looked at the logs yet)

Ah, I'd forgotten about that.  When I first tried to run python I got an error complaining about a missing api-ms-win-crt-runtime-l1-1.0.dll
I installed the necessary VC redistributable and it solved that problem.  So that's why I could successfully ensurepip later on.

I'm surprised the manual runtime installation was necessary.  Between windows updates and installers for other programs I should already have it installed.  Perhaps it got corrupted?  That's out of scope for this issue anyway.

This issue is similar to bpo-25117 in terms of the installer failing to run Python for post-installation tasks. The complication in this case is that a subsequent repair doesn't install pip.

This was caused by the UCRT not installing properly. These days, the UCRT is installed app-local for Win 8.1, and is already present on Win 10, so it can't happen anymore.