Windows: subprocess won't run different Python interpreter

eryk sun eryksun at gmail.com
Fri Nov 11 01:23:50 EST 2016


On Fri, Nov 11, 2016 at 6:01 AM, Thorsten Kampe
<thorsten at thorstenkampe.de> wrote:
> * eryk sun (Thu, 10 Nov 2016 23:04:02 +0000)
>>
>> On Thu, Nov 10, 2016 at 9:58 PM, Thorsten Kampe
>> <thorsten at thorstenkampe.de> wrote:
>> >
>> > I'm trying to run a script with a different Python version by
>> > extending the path variable and executing "python.exe". It looks like
>> > subprocess will always run the current executing Python.
>>
>> WinAPI CreateProcess checks the application directory, current
>> directory (an insecure legacy default), %SystemRoot%\System32,
>> %SystemRoot%\System, %SystemRoot%, and then the directories in %PATH%.
>> This is listed in the documentation of the lpCommandLine parameter on
>> MSDN [1].
>
> I'm aware of that. Python is in F:\PortableApps\Python3x and neither
> the current directory nor the PATH points to that.

That's the application directory, which is the first place
CreateProcess looks (via the SearchPath call), as both of my examples
shows. In my case python.exe is located in the standard 3.5 system
installation path, "C:\Program Files\Python35".

I showed how to remove the current directory from the search. But, in
hindsight, I should have clarified that the working directory was not
related to your problem. It's just the only directory that can be
removed from the implicit search path (AFAIK). I thought about
replying with a clarification, but it seemed clear in context that the
source of the behavior was the application directory.

I know of no API, environment variable, or manifest setting to remove
the application directory from the head of the search path used by
CreateProcess. What you can do is call SearchPath explicitly (via
PyWin32 or ctypes) with just %Path%, or do the search in pure Python
via shutil.which.

Note also that LoadLibrary uses a separate DLL search path that also
defaults to preferring the application directory, but this can be
controlled by calling SetDefaultDllDirectories [1], among other
strategies.

[1]: https://msdn.microsoft.com/en-us/library/hh310515



More information about the Python-list mailing list