The Python 3.8 for Windows installer has an option to add the install folder to the path environment variable. It adds the path to the front of the list so that it is the first item. According to my understanding, this is bad behavior. It should add new path items to the end of the list because Windows searches in order. c:\windows\system32 should remain the first item in the list. This is a classic mistake of installers.

Prepending directories ahead of system directories in PATH affects programs that implement their own search, which includes shells such as cmd.exe that do so in order to support PATHEXT efficiently. That said, note that temporarily prepending to PATH in a particular environment is common. Consider an activated virtual environment or a developer command prompt.

Usually programs defer to a Windows API function when searching for a file. The API uses search paths from the runtime library functions RtlGetSearchPath, RtlGetExePath, and LdrGetDllPath.

With WINAPI SearchPathW, the default search path is from RtlGetSearchPath (undocumented). It includes the following directories in non-safe search mode (the default mode):

  1. %__APPDIR__%
  2. %__CD__%
  3. %SystemRoot%\System32
  4. %SystemRoot%\System
  5. %SystemRoot%
  6. %PATH%

and the following adjusted order in safe search mode:

  1. %__APPDIR__%
  3. %SystemRoot%\System32
  4. %SystemRoot%\System
  5. %SystemRoot%
  2. %__CD__%
  6. %PATH%

Safe search mode can be set via WINAPI SetSearchPathMode(BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE).

With WINAPI CreateProcessW, the search path is from RtlGetExePath (undocumented). This is similar to the result from RtlGetSearchPath, except, instead of supporting a safe search mode, RtlGetExePath allows excluding the current directory (%__CD__%) from the search path by setting the environment variable NoDefaultCurrentDirectoryInExePath.

With WINAPI LoadLibrary[Ex]W, the system uses the search path from LdrGetDllPath (undocumented). The default DLL search path at startup under normal circumstances is the same as the safe-mode result from RtlGetSearchPath -- except for special casing of known system DLLs and API sets.

Yes, it is bad behaviour, but it is very upsetting for many people to not have the option. This is why it's disabled by default, and why I regularly discourage people from selecting the option (and quite often get abused for taking the trouble... oh well... that's apparently how open-source life works these days).

If you install just for the current user, it will only appear ahead of the user's own PATH entries, which are stored separately from the system ones and concatenated automatically (unless the whole thing exceeds a certain length, in which case you just lose PATH entries... another reason to avoid it).

Adding to the end of the PATH would leave people broken and confused as any other install of Python would still take precedence. So to minimize breakage, it goes to the front, but the per-user install is the default.

So thanks for the support, but unfortunately we don't have any viable way to move forward on it. Tell people not to add to PATH and to run py.exe instead - which we've been doing for years, but it doesn't really have much effect.

Just a note to add my full support for what Steve said.  PATH is frequently abused on Windows, and we only have the option at all because people become unreasonably upset if it's not there.  I wouldn't be against adding a "you don't actually want this, use py.exe" note to the option, though :)