3.15: Lazy imports break with __getattr__ (concurrent.futures)

[henryiii]

Bug report

Bug description:

Under 3.15, this doesn't work:

lazy from concurrent.futures import ProcessPoolExecutor


def square(x):
    return x * x


def main():
    with ProcessPoolExecutor(max_workers=2) as executor:
        results = list(executor.map(square, [1, 2, 3, 4]))
    print(results)


if __name__ == "__main__":
    main()

(I'm running with uv run --python=3.15 lazy.py) Without the lazy this works. If you use lazy import concurrent.futures it works. It also breaks in __lazy_modules__ form (which is how I ran into it). It breaks with ThreadPoolExecutor too.

The (rather poor) error message:

Traceback (most recent call last):
  File "/Users/henryfs/git/tmp/cpylazyproc/lazy.py", line 1, in <module>
    lazy from concurrent.futures import ProcessPoolExecutor
ImportError: deferred import of 'concurrent.futures.ProcessPoolExecutor' raised an exception during resolution

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Users/henryfs/git/tmp/cpylazyproc/lazy.py", line 15, in <module>
    main()
    ~~~~^^
  File "/Users/henryfs/git/tmp/cpylazyproc/lazy.py", line 9, in main
    with ProcessPoolExecutor(max_workers=2) as executor:
         ^^^^^^^^^^^^^^^^^^^
ImportError: cannot import name 'ProcessPoolExecutor' from 'concurrent.futures' (/Users/henryfs/.local/share/uv/python/cpython-3.15.0b1-macos-aarch64-none/lib/python3.15/concurrent/futures/__init__.py)

I believe this is broken because concurrent.futures has a classic lazy import hack:

cpython/Lib/concurrent/futures/__init__.py

Lines 50 to 65 in b980552

	def __getattr__(name):
	global ProcessPoolExecutor, ThreadPoolExecutor, InterpreterPoolExecutor
	if name == 'ProcessPoolExecutor':
	from .process import ProcessPoolExecutor
	return ProcessPoolExecutor
	if name == 'ThreadPoolExecutor':
	from .thread import ThreadPoolExecutor
	return ThreadPoolExecutor
	if _interpreters and name == 'InterpreterPoolExecutor':
	from .interpreter import InterpreterPoolExecutor
	return InterpreterPoolExecutor
	raise AttributeError(f"module {__name__!r} has no attribute {name!r}")

I think there are two issues:

• Lazy imports ideally shouldn't break this hack, unless there's something fundamental that can't be fixed
• This hack should be replaced with lazy imports (now that =none has been removed, it should be safe)

CPython versions tested on:

3.15

Operating systems tested on:

macOS

Linked PRs

• gh-150579: use lazy imports for concurrent.futures #150585

[StanFromIreland]

I presume it's duplicate of #144957, are you testing with the 3.15 branch or the latest release?

[henryiii]

Ahh, I didn't find that, I think I only looked at open issues with "lazy" in the title! I just build 3.15 and can confirm this works now.

Would moving concurrent.futures from the old workaround to using lazy modules be something to still do? Otherwise this can be closed.

diff --git a/Lib/concurrent/futures/__init__.py b/Lib/concurrent/futures/__init__.py
index d6ac4b3e0b6..63e2a647e40 100644
--- a/Lib/concurrent/futures/__init__.py
+++ b/Lib/concurrent/futures/__init__.py
@@ -17,6 +17,9 @@
                                       wait,
                                       as_completed)

+lazy from .process import ProcessPoolExecutor
+lazy from .thread import ThreadPoolExecutor
+
 __all__ = [
     'FIRST_COMPLETED',
     'FIRST_EXCEPTION',
@@ -40,26 +43,10 @@
     _interpreters = None

 if _interpreters:
+    lazy from .interpreter import InterpreterPoolExecutor
     __all__.append('InterpreterPoolExecutor')


 def __dir__():
     return __all__ + ['__author__', '__doc__']

-
-def __getattr__(name):
-    global ProcessPoolExecutor, ThreadPoolExecutor, InterpreterPoolExecutor
-
-    if name == 'ProcessPoolExecutor':
-        from .process import ProcessPoolExecutor
-        return ProcessPoolExecutor
-
-    if name == 'ThreadPoolExecutor':
-        from .thread import ThreadPoolExecutor
-        return ThreadPoolExecutor
-
-    if _interpreters and name == 'InterpreterPoolExecutor':
-        from .interpreter import InterpreterPoolExecutor
-        return InterpreterPoolExecutor
-
-    raise AttributeError(f"module {__name__!r} has no attribute {name!r}")

From a quick check, this seems to pass the test suite.