3.14.0a1: `_pickle.PicklingError: Can't pickle local object` when a multiprocessing.Process is started with target function defined in a function

[befeleme]

Bug report

Bug description:

I encountered pickling issue (originally when building redis for Fedora Linux) when a multiprocessing.Process is started with target being a function defined in a function. Python 3.14.0a1 fails with the PicklingError.
This has happened in at least 5 packages we've got in Fedora, typically in testing functions: redis, etcd, iniparse, readability-lxml, satyr.

The default method in Linux has changed per What's new document (https://docs.python.org/3.14/whatsnew/3.14.html#multiprocessing). Is this expected? Is this a regression? In Python 3.13 there's no issue with this code.

import multiprocessing

def main():
    def func():
        pass

    proc = multiprocessing.Process(target=func)
    proc.start()
    proc.join(3)
    return proc.exitcode

if __name__ == '__main__':
    print(main())

Python 3.13:

0

Python 3.14.0a1:

Traceback (most recent call last):
  File "<python-input-0>", line 12, in <module>
    print(main())
          ~~~~^^
  File "<python-input-0>", line 8, in main
    proc.start()
    ~~~~~~~~~~^^
  File "/usr/lib64/python3.14/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
                  ~~~~~~~~~~~^^^^^^
  File "/usr/lib64/python3.14/multiprocessing/context.py", line 224, in _Popen
    return _default_context.get_context().Process._Popen(process_obj)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib64/python3.14/multiprocessing/context.py", line 300, in _Popen
    return Popen(process_obj)
  File "/usr/lib64/python3.14/multiprocessing/popen_forkserver.py", line 35, in __init__
    super().__init__(process_obj)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib64/python3.14/multiprocessing/popen_fork.py", line 20, in __init__
    self._launch(process_obj)
    ~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib64/python3.14/multiprocessing/popen_forkserver.py", line 47, in _launch
    reduction.dump(process_obj, buf)
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.14/multiprocessing/reduction.py", line 60, in dump
    ForkingPickler(file, protocol).dump(obj)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^
_pickle.PicklingError: Can't pickle local object <function main.<locals>.func at 0x7f721468a8d0>
when serializing dict item '_target'
when serializing multiprocessing.context.Process state
when serializing multiprocessing.context.Process object

CPython versions tested on:

3.14, main branch

Operating systems tested on:

Linux

[vstinner]

The default method in Linux has changed per What's new document (https://docs.python.org/3.14/whatsnew/3.14.html#multiprocessing). Is this expected? Is this a regression? In Python 3.13 there's no issue with this code.

I confirm that the reproducer started to fail since commit b65f2cd:

commit b65f2cdfa77d8d12c213aec663ddaaa30d75a4b2
Author: Gregory P. Smith <greg@krypto.org>
Date:   Thu Sep 26 16:57:19 2024 -0700

    gh-84559: Change the multiprocessing start method default to `forkserver` (GH-101556)
    
    Change the default multiprocessing start method away from fork to forkserver or spawn on the remaining platforms where it was fork.  See the issue for context.  This makes the default far more thread safe (other than for people spawning threads at import time... - don't do that!).
    
    Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com>
    Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>

The reproducer also fails on Python 3.13 if modified to use the "spawn" start method:

import multiprocessing

def main():
    def func():
        pass

    multiprocessing.set_start_method('spawn')
    proc = multiprocessing.Process(target=func)
    proc.start()
    proc.join(60)
    return proc.exitcode

if __name__ == '__main__':
    print(main())

The workaround is to use the "fork" start method:

multiprocessing.set_start_method('fork')

cc @gpshead

[gpshead]

This is expected. Though this error message doesn't point people in the right direction so we may want to do something to improve that as a way to smooth peoples transition. Closing as a dupe of #125714.