The install model has been very different on the other side of the fence. In the past (well, in every Python until 3.3), the Windows installer updated the global Windows registry such that the latest Python version installed on your computer was the version that opened Python files when they were clicked or run by direct filename in command lines.

Some Windows users may know this registry as filename associations, configurable in Control Panel’s Default Programs dialog. You do not need to give files executable privileges for this to work, as you do for Unix scripts. In fact, there’s no such concept on Windows—filename associations and commands suffice to launch files as programs.

Under this install model, if you wished to open a file with a different version than the latest install, you had to run a command line giving the full path to the Python you wanted, or update your filename associations manually to use the desired version. You could also point generic python command lines to a specific Python by setting or changing your PATH setting, but Python didn’t set this for you, and this wouldn’t apply to scripts launched by icon clicks and other contexts.

This reflects the natural order on Windows (when you click on a .doc file, Windows usually opens it in the latest Word installed), and has been the state of things ever since there was a Python on Windows. It’s less ideal if you have Python scripts that require different versions on the same machine, though—a situation that has become increasingly common, and perhaps even normal in the dual Python 2.X/3.X era. Running multiple Pythons on Windows prior to 3.3 can be tedious for developers, and discouraging for newcomers.