New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LazyLoader rejecting use of SourceFileLoader #70374
Comments
It was privately reported to me that importlib.util.LazyLoader rejects using importlib.machinery.SourceFileLoader (or at least _frozen_importlib.SourceFileLoader). At least a test should be added for LazyLoader to make sure it will happily accept importlib.machinery.SourceFileLoader, and if it rejects the one from _frozen_importlib, tweak the test to accept loaders from there as well. |
One way to possibly improve this is to remove the create_module() check and replace it with a warning if create_module() doesn't return None. Another option is to use an assert statement. The final option is to just drop the check entirely, although that can make debugging difficult. |
I think I'm liking the following approach: if __debug__:
hopefully_None = loader.create_module(spec)
if hopefully_None is not None:
warnings.warn("watch out!", ImportWarning) |
Just stumbled on this very issue while trying to use LazyLoader. |
My current plan is to simply remove the check in 3.5 -- the docs say it's ignored so I don't think it will hurt anything -- and add the warning I proposed in 3.6. What do you think, Antoine? |
By the way does this mean the LazyLoader won't work with ExtensionFileLoader? That would reduce its usefulness quite a bit. |
I don't know what the impact of the error is, but it seems like at least the default loader classes should be able to work with LazyLoader... |
You're right, it won't work with extension modules based on how ExtensionFileLoader is structured. |
New changeset 9f1e680896ef by Brett Cannon in branch '3.5': New changeset 86fc6cdd65de by Brett Cannon in branch 'default': |
This has been resolved by removing the check (the docs have always said the method was ignored, so that will just continue). I also did separate commit to list that BuiltinImporter and ExtensionFileLoader won't work (they would need to be updated to return a module subclass to work). I'm leaving this issue open to decide if I want to add an explicit check in importlib.util.LazyLoader.create_module() to verify that None is returned in Python 3.5 (I probably will, but I want to think about on it for a little bit). |
I actually think this can be generalized thanks to some tweaks made in Python 3.6 which will lead to it working with extension modules. I need to double-check, but I think I can:
|
New changeset 7af4b3ad75b7 by Brett Cannon in branch 'default': |
The restriction of lazily loading built-ins and extensions is now lifted! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: