InterpreterPoolExecutor Raises Attribute Error on Lambdas

[paultiq]

Bug report

Bug description:

3.14.0a1+ 34653bb, Windows 64bit

The following code raises an attribute error:

from concurrent.futures.interpreter import InterpreterPoolExecutor

with InterpreterPoolExecutor() as executor:
    future = executor.submit(lambda x: 10)
    
result = future.result() 
print(result)

This code runs:

from concurrent.futures import ThreadPoolExecutor

with ThreadPoolExecutor() as executor:
    future = executor.submit(lambda: 10)

result = future.result()  # Get the result of the function
print(result)

Error:

AttributeError: module '__main__' has no attribute '<lambda>'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\scratch\cpython\PCbuild\amd64\test1.py", line 4, in <module>
    future = executor.submit(lambda: 10)
  File "C:\scratch\cpython\Lib\concurrent\futures\thread.py", line 210, in submit
    task = self._resolve_work_item_task(fn, args, kwargs)
  File "C:\scratch\cpython\Lib\concurrent\futures\interpreter.py", line 64, in resolve_task
    data = pickle.dumps((fn, args, kwargs))
_pickle.PicklingError: Can't pickle <function <lambda> at 0x000001455882EDA0>: it's not found as __main__.<lambda>
when serializing tuple item 0

CPython versions tested on:

CPython main branch

Operating systems tested on:

Windows

[paultiq]

Unclear if related to #125864, so I filed separately, but they're similar.

[ZeroIntensity]

Yeah, lambdas can't get picked. I don't think there's anything that can be done.

[paultiq]

From the doc, https://github.com/python/cpython/blob/main/Doc/library/concurrent.futures.rst, I expected InterpreterPoolExecutor to behave similarly to ThreadPoolExecutor... yet in this regards, it behaves similar to ProcessPoolExecutor.

The opening paragraph says: "It is a :class:ThreadPoolExecutor subclass, which means each worker is running in its own thread.", which perhaps could be clarified that certain behaviors are more consistent with ProcessPoolExecutor.

** In short: the docs led me to expect that code that runs on a ThreadPoolExecutor would, generally speaking, work in a InterpreterPoolExecutor... a clearer comment up top that this isn't the case may avoid some user errors like this one.