You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
inspect.getframeinfo forces all lazy modules to be loaded #139669
The inspect module's getframeinfo(frame, context) calls getmodule(frame, file) and that creates a module / filename cache by iterating through sys.modules & accessing their attributes. Since lazy_import(name) adds the lazy module to sys.modules, sys.modules[name] = module - the lazy module gets initialized when accessing the attribute (see "__getattribute__" in LazyModule for more info on accessing attrs).
Need someone with more expertise in stdlibs to comment on if there's a possible workaround but the mutation checks for the lazy module attributes is the reason the module is being loaded.
On hindsight, it seems like the inspect module only accesses the __file__ attribute of sys.modules. If it's ok to have an early return on certain immutable attributes that are derived from ModuleSpec metadata in LazyModule (like file in this instance), then we could evade the issue. Looking forward to thoughts from others, I have a working fix if this gets the ok.
Just my two cents: I think it's the expected behavior? The lazy module should be triggered to load at the time it is firstly accessed, wherever this happens, in user code or in first-party libraries.
Yep, I agree accessing a lazy module's attributes triggering a load is expected. I still think it's not ideal that an introspection tool has a side effect of executing lazy modules. The mutated values tracking only checks for non-metadata attributes i.e. '__dict__', therefore I think a change might be warranted (?) to early return metadata attributes. @picnixz
I agree with xuantengh. While it's not ideal as a side-effect, lazy modules are really meant to be lazy until they are needed. Here, we "somehow" need it as a side effect but making special cases isn't enough IMO. inspect is known to create side-effects, either by evaluating signatures, or other stuff like that. With PEP-810 being accepted, I'm not sure that it will be the case anymore, so I would first close the issue now and possibly re-open it for 3.15 and later if this behavior is still inacceptable.
OTOH, if we were to pre-load some attributes on the lazy module, maybe.. it could work?
We just noticed this (indirectly and there the core issue can be argued to not be this). FWIW, I think this is an issue that would be nice to address (although, yeah, PEP-810 may not suffer from the same issue and replace this eventually).
The problem isn't that there are side-effects and inspect.<something>(lazy_module) loads the module after all.
But using someinspect API e.g. during import should be reasonable and not break all other loaded modules decision to do lazy imports to speed things up.
OTOH, if we were to pre-load some attributes on the lazy module, maybe.. it could work?
Well, there are two possible solutions here, I think, assuming that overriding __file__ on a module is crazy:
Just define __file__ to module.__spec__.origin on the _LazyModule which is probably enough for inspect to get things right.
Have inspect know about importlib.util._LazyModule? E.g. trying module.__spec__.origin rather than __file__ first in the inspect module might be sufficient to not rely on it directly?
Activity
ramicats commentedon Oct 7, 2025
The inspect module's
getframeinfo(frame, context)callsgetmodule(frame, file)and that creates a module / filename cache by iterating through sys.modules & accessing their attributes. Since lazy_import(name) adds the lazy module to sys.modules,sys.modules[name] = module- the lazy module gets initialized when accessing the attribute (see "__getattribute__" in LazyModule for more info on accessing attrs).Need someone with more expertise in stdlibs to comment on if there's a possible workaround but the mutation checks for the lazy module attributes is the reason the module is being loaded.
ramicats commentedon Oct 7, 2025
On hindsight, it seems like the inspect module only accesses the
__file__attribute of sys.modules. If it's ok to have an early return on certain immutable attributes that are derived from ModuleSpec metadata in LazyModule (like file in this instance), then we could evade the issue. Looking forward to thoughts from others, I have a working fix if this gets the ok.xuantengh commentedon Oct 8, 2025
Just my two cents: I think it's the expected behavior? The lazy module should be triggered to load at the time it is firstly accessed, wherever this happens, in user code or in first-party libraries.
ramicats commentedon Oct 8, 2025
Yep, I agree accessing a lazy module's attributes triggering a load is expected. I still think it's not ideal that an introspection tool has a side effect of executing lazy modules. The mutated values tracking only checks for non-metadata attributes i.e. '__dict__', therefore I think a change might be warranted (?) to early return metadata attributes. @picnixz
picnixz commentedon Dec 31, 2025
I agree with xuantengh. While it's not ideal as a side-effect, lazy modules are really meant to be lazy until they are needed. Here, we "somehow" need it as a side effect but making special cases isn't enough IMO.
inspectis known to create side-effects, either by evaluating signatures, or other stuff like that. With PEP-810 being accepted, I'm not sure that it will be the case anymore, so I would first close the issue now and possibly re-open it for 3.15 and later if this behavior is still inacceptable.OTOH, if we were to pre-load some attributes on the lazy module, maybe.. it could work?
cc @serhiy-storchaka
seberg commentedon May 29, 2026
We just noticed this (indirectly and there the core issue can be argued to not be this). FWIW, I think this is an issue that would be nice to address (although, yeah, PEP-810 may not suffer from the same issue and replace this eventually).
The problem isn't that there are side-effects and
inspect.<something>(lazy_module)loads the module after all.But using some
inspectAPI e.g. during import should be reasonable and not break all other loaded modules decision to do lazy imports to speed things up.Well, there are two possible solutions here, I think, assuming that overriding
__file__on a module is crazy:__file__tomodule.__spec__.originon the_LazyModulewhich is probably enough for inspect to get things right.inspectknow aboutimportlib.util._LazyModule? E.g. tryingmodule.__spec__.originrather than__file__first in theinspectmodule might be sufficient to not rely on it directly?serhiy-storchaka commentedon May 29, 2026
Setting
__file__may also fix other code that checks__file__. cc @brettcannonxuantengh commentedon Jun 1, 2026
We should also set
__name__of_LazyModuleto avoidinspectloading the lazy module. May I propose a PR for this?