Python Launcher for Windows provides some important value for Windows users, but its ability to invoke python versions not on the PATH is a problem.

py.exe chooses a version of Python to invoke, in more or less this order of decreasing priority; it is the *last* one that occurs by default in a new install of python 3.3.x:

1. Shebang line in myscript.py

2. py.exe -n argument (n can be 2, 3, 3.2 etc). Launcher chooses the latest installed version so specified.

3. PY_PYTHON environment variable

4. py.ini in C:\WINDOWS or user's %LOCALAPPDATA% directory

5. Launcher hunts through registry for ALL previously installed pythons, and picks the latest version in the 2.x series. DEFAULT.

The first issue to note is that, to my knowledge, the exact precedence order is not documented... it would greatly help if this were done.

That said, the focus in this report is case 5, which as noted is the default behavior when python 3.3.2 is installed (and py.exe invoked with scripts having no launcher-aware shebang line).

In case 5, py.exe completely ignores the PATH environment variable. So, whereas PATH is used to find py.exe, or when the user invokes 'python' on the command line, py.exe ignores PATH and launches a version of python that is not necessarily in the PATH.

In case 2 where the user supplies a value for 'n', finding a non-PATH version of python is excusable on the basis that the user deliberately requests a version.

However, in case 5, the user is not invoking py explicitly, and is not necessarily aware of py's algorithm for finding all installed versions. The user might reasonably expect that invoking a script or double clicking it would just invoke 'python' the same as the 'python' command, using PATH.

In particular, if the user understands how PATH works (as reviewed in the docs here: http://docs.python.org/3/using/windows.html#finding-the-python-executable), then upon installing 3.3.x, he or she might explicitly *remove* python 2.x from PATH in the expectation that this will disable python 2.x. It is surprising and potentially harmful that py.exe does not abide by that choice.

A potential improvement is to interpose an item '4.5' in the above list, in which py.exe looks for a version of python on the PATH before falling back to searching for latest 2.x python ever installed.

(It is not clear that py.exe should *ever* fallback to just picking the latest 2.x in the registry (item 5). It is conceivable that a user may have configured one of those pythons to do something destructive or insecure on startup, and it will be a great surprise if py.exe "randomly" invokes it just because it has the highest version number.)