Bug report

Bug description:

The following code, invoked with python3 ~/test.py foo:

import multiprocessing
import sys
print("args in module", sys.argv[1:])
def fun():
 print("args in fun", sys.argv[1:])
if __name__ == "__main__":
 multiprocessing.set_start_method("forkserver")
 fun()
 p = multiprocessing.Process(target=fun)
 p.start()
 p.join()

prints the following results on Python 3.12, 3.13.4, and 3.14.0b3:

args in module ['foo']
args in fun ['foo']
args in module ['foo']
args in fun ['foo']

but on Python 3.13.11 and 3.14.2 prints the following results:

args in module ['foo']
args in fun ['foo']
args in module []
args in fun ['foo']

For whatever reason, these latter versions change forkserver to set up sys.argv after the main module is imported, instead of before. As far as I can tell, the former results are always printed using spawn; that always sets up sys.argv before the main module is imported.

If the code depends on sys.argv in the main module, then the subprocess does not do the same thing as the main process and bad things can happen.

This change tripped me up when fixing a program for the new forkserver default. It's unclear if it's a bug, because I admit our program is naughty about running code in a module like this, but this may be something to fix and at least may serve as documentation of a pitfall for others even if there is nothing to change.

CPython versions tested on:

3.12, 3.13, 3.14

Operating systems tested on:

Linux