I don't know how much should be documented for subprocess.Popen, but here are the details for how searching works with shell=False (default) and shell=True.

For shell=False, the search path used by WinAPI CreateProcessW checks %__APPDIR__%; %__CD__% (unless %NoDefaultCurrentDirectoryInExePath% is defined and the name to search contains no backslashes); %SystemRoot%\System32; %SystemRoot%\System; %SystemRoot%; and then the %PATH% directories. The search path is passed to WinAPI SearchPathW, with a default ".exe" extension. SearchPathW tries to resolve a relative path (but not a drive-relative or rooted-relative path) against every directory in the search path, unless it explicitly begins with a "." or ".." component. For the relative case, it appends the default ".exe" extension to a name if and only if it has no extension (a trailing "." counts as an extension). For the non-relative case, it first tries to find the name as given and then with the default extension appended, even if the filename already has an extension (no exception is made for a trailing dot, i.e. searching for "C:\Temp\spam." will check for "spam." and then "spam..exe").

From the POSIX perspective, the implicit inclusion of the application directory, working directory, and system directories is strange and, regarding the inclusion of the working directory, troubling. The fact that searching for a relative name with one or more slashes, such as "spam\\python", is not resolved against *only* the working directory is strange and not documented. The rules governing when ".exe" will be appended are complicated and incorrectly documented (e.g. the claim "if the file name contains a path, .exe is not appended").

With shell=True, the CMD shell simply checks %__CD__% (unless %NoDefaultCurrentDirectoryInExePath% is defined and the name to search contains no slashes) and %PATH%. Support for forward slash in the name to search is wonky; it works only for quoted paths. But at least a relative path that contains slashes is only resolved against the current working directory instead of every directory in the search path. CMD's rules for appending default extensions are simpler than SearchPathW in some ways, but also more complicated because it's generalized as the PATHEXT list of extensions. In each directory, CMD always looks first for the searched name as given and then the name plus each extension in PATHEXT, regardless of the filepath type or whether the searched name already has an extension. It will not find a name that has no extension unless PATHEXT includes a "." entry for the empty extension. (This is consistent with the desktop shell API, which supports defining an association for the "." filetype.)