Circular import error for `threading` when using `importlib.util.LazyLoader` with a custom finder

[Sachaa-Thanasius]

Bug report

Bug description:

When using a custom finder (on sys.meta_path) that wraps a module spec's loader with importlib.util.LazyLoader, the threading import within importlib.util.LazyLoader.exec_module is attempted with the custom finder, causing a circular import error.

Not sure if this is more of a feature request than a bug report, but the behavior was certainly surprising at first glance. Hopefully there's a way to better support this use case from within the stdlib without too much burden. Otherwise, users of LazyLoader in this manner would be forced to either a) maintain an exclusion list of modules that their finder ignores, potentially including all of threading's dependencies or b) always import threading before using such finders, which shouldn't be necessary, especially if threading isn't directly used by the user code.

Reproducer

import importlib.util
import sys

class LazyFinder:
    """A module spec finder that wraps a spec's loader, if it exists, with LazyLoader."""

    @classmethod
    def find_spec(cls, fullname: str, path=None, target=None, /):
        for finder in sys.meta_path:
            if finder is not cls:
                spec = finder.find_spec(fullname, path, target)
                if spec is not None:
                    break
        else:
            raise ModuleNotFoundError(...)

        if spec.loader is not None:
            spec.loader = importlib.util.LazyLoader(spec.loader)

        return spec


class LazyFinderContext:
    """Temporarily "lazify" some types of import statements in the runtime context."""
    
    def __enter__(self):
        if LazyFinder not in sys.meta_path:
            sys.meta_path.insert(0, LazyFinder)

    def __exit__(self, *exc_info):
        try:
            sys.meta_path.remove(LazyFinder)
        except ValueError:
            pass

with LazyFinderContext():
    import inspect

Expected Output

No error.

Actual Output

> python scratch.py
Traceback (most recent call last):
  File "/home/thanos/projects/personal/pycc/scratch.py", line 40, in <module>
    import inspect
  File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
  File "<frozen importlib.util>", line 257, in exec_module
  File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
  File "<frozen importlib.util>", line 267, in exec_module
AttributeError: partially initialized module 'threading' has no attribute 'RLock' (most likely due to a circular import)

Commentary

This is technically caused by this code:

cpython/Lib/importlib/util.py

Lines 256 to 260 in 9dabace

	def exec_module(self, module):
	"""Make the module load lazily."""
	# Threading is only needed for lazy loading, and importlib.util can
	# be pulled in at interpreter startup, so defer until needed.
	import threading

However, it is based on the fair assumptions that LazyLoader a) isn't critical to CPython startup, and b) won't be used in a circular fashion with a custom finder. However, there are use cases for such a finder (e.g. scientific-python/lazy-loader#121 (comment), one place this issue was discovered). While finders utilizing the lazy loader could work around this with an exclusion list of modules (e.g. mercurial's lazy loader does), I think users would find using LazyLoader easier with the finder-related import hooks if that wasn't necessary.

Based on the commit history, a top-level import for threading breaks gevent, so I'd rather not repeat that. I'm not very familiar with gevent, but if using _thread.RLock is fine in importlib._bootstrap for the module locks, then maybe that could be used in importlib.util as well?

EDIT: Updated code snippet to be consistent with output; accidentally used a different import while testing. Still, same result.

CPython versions tested on:

3.12, 3.13

Operating systems tested on:

Linux, Windows