On Unix-like systems, the function multiprocessing.set_executable accepts any path-like objects (str, bytes, and os.PathLike) as its executable argument for setting up the path to the Python interpreter multiprocessing.spawn._python_exe.

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 execute any program in the child process;

• the ‘spawn’ start method converts multiprocessing.spawn._python_exe to bytes with os.fsencode before passing it to the function _posixsubprocess.fork_exec to create a child process, and bytes is the expected argv argument type:

          return _posixsubprocess.fork_exec(
              args, [os.fsencode(path)], True, passfds, None, None,
              -1, -1, -1, -1, -1, -1, errpipe_read, errpipe_write,
              False, False, None, None, None, -1, None)
  

• 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).

But on Windows, the ‘spawn’ start method (the only start method available on this O.S.) does not convert multiprocessing.spawn._python_exe to str with os.fsdecode before passing it to the function _winapi.CreateProcess to create a child process, whereas str is the expected application_name argument type:

                hp, ht, pid, tid = _winapi.CreateProcess(
                    python_exe, cmd,
                    None, None, False, 0, env, None, None)

So on Windows the function multiprocessing.set_executable accepts only str objects as its executable argument. This pull request fixes this to be on a par with Unix-like systems for which the function accepts any path-like objects.

https://bugs.python.org/issue46720