You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add support for path-like objects to multiprocessing.set_executable for Windows to be on a par with Unix-like systems #90876
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=Nonecreated_at=<Date2022-02-11.14:57:09.587>labels= ['type-feature', 'library', '3.9', '3.10', '3.11']
title='Add support for path-like objects to multiprocessing.set_executable for Windows to be on a par with Unix-like systems'updated_at=<Date2022-02-11.22:25:00.201>user='https://github.com/maggyero'
This is because the ‘fork’ start method does not exec any program in the subprocess, the ‘spawn’ start method converts its path argument to bytes with os.fsencode before passing to _posixsubprocess.fork_exec, and the ‘forkserver’ start method spawns a server process (like with the ‘spawn’ start method) which then forks itself at each request (like the ‘fork’ start method):
Linux (and other Unix-like systems) uses the same code than MacOS for the three start methods so it should work for it too.
However I have not tested this on Windows which uses the function _winapi.CreateProcess for the ‘spawn’ start method (the only start method available on this OS) but I noticed that no conversion to str (not to bytes this time, since the function expects str) of the path argument with os.fsdecode (not os.fsencode this time) is performed before passing it to the function:
So on Windows only str path can be passed to multiprocessing.set_executable. This PR fixes this to be on a par with Unix-like systems which accept any path-like objects.
changed the title [-]Add support of path-like objects to multiprocessing.set_executable for Windows to match Unix-like systems[/-][+]Add support for path-like objects to multiprocessing.set_executable for Windows to be on a par with Unix-like systems[/+]on Feb 11, 2022
changed the title [-]Add support of path-like objects to multiprocessing.set_executable for Windows to match Unix-like systems[/-][+]Add support for path-like objects to multiprocessing.set_executable for Windows to be on a par with Unix-like systems[/+]on Feb 11, 2022
Activity
maggyero commentedon Feb 11, 2022
Any path-like object can be passed to
multiprocessing.set_executable, i.e. objects withstr,bytes, oros.PathLiketype.For instance these work (tested on MacOS with all start methods: ‘spawn’, ‘fork’, and ‘forkserver’):
multiprocessing.set_executable(sys.executable)(str);multiprocessing.set_executable(sys.executable.encode())(bytes);multiprocessing.set_executable(pathlib.Path(sys.executable))(os.PathLike).This is because the ‘fork’ start method does not exec any program in the subprocess, the ‘spawn’ start method converts its path argument to
byteswithos.fsencodebefore passing to_posixsubprocess.fork_exec, and the ‘forkserver’ start method spawns a server process (like with the ‘spawn’ start method) which then forks itself at each request (like the ‘fork’ start method):Linux (and other Unix-like systems) uses the same code than MacOS for the three start methods so it should work for it too.
However I have not tested this on Windows which uses the function
_winapi.CreateProcessfor the ‘spawn’ start method (the only start method available on this OS) but I noticed that no conversion tostr(not tobytesthis time, since the function expectsstr) of the path argument withos.fsdecode(notos.fsencodethis time) is performed before passing it to the function:So on Windows only
strpath can be passed tomultiprocessing.set_executable. This PR fixes this to be on a par with Unix-like systems which accept any path-like objects.[-]Add support of path-like objects to multiprocessing.set_executable for Windows to match Unix-like systems[/-][+]Add support for path-like objects to multiprocessing.set_executable for Windows to be on a par with Unix-like systems[/+][-]Add support of path-like objects to multiprocessing.set_executable for Windows to match Unix-like systems[/-][+]Add support for path-like objects to multiprocessing.set_executable for Windows to be on a par with Unix-like systems[/+]brettcannon commentedon Apr 22, 2022
Closed via #31279 .
pythongh-90876: Prevent a multiprocessing import error.
gh-90876: Restore the ability to import multiprocessing when `sys.exe…
pythongh-90876: Restore the ability to import multiprocessing when `s…
pythongh-90876: Restore the ability to import multiprocessing when `s…
[3.12] gh-90876: Restore the ability to import multiprocessing when `…
[3.11] gh-90876: Restore the ability to import multiprocessing when `…