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
Consider leaving importlib.abc.Loader.load_module() #65635
Comments
It was very easy to load plugin files in Python 2: import imp
my_module = imp.load_source("what.ever", "foo.py") Unfortunately, this became much more obscure in Python 3.3: import importlib.machinery
loader = importlib.machinery.SourceFileLoader("what.ever", "foo.py")
my_module = loader.load_module("what.ever") In Python 3.4 even this has been deprecated. There should be a way (preferable an easy-to-use one) to load a Python module by filename or by stream. |
So it's not quite as bad as you think as SourceFileLoader.load_module() doesn't need an argument (I've opened http://bugs.python.org/issue21438 to fix the documentation). Admittedly it is a longer command than imp.load_source() to type, but there is no extra information required or a necessity that you break the command up into multiple lines. Plus imp.load_source() is just plain bad. The reason the imp module is deprecated in Python 3.4 is because it does not expose the low-level details of import in a way that makes any sense since Python 2.3 (and yes, I meant to write 2.3 instead of 3.3; the problem has persisted _that_ long). That being said, talks are just starting to consider undoing the documented deprecation of load_module() such that you can continue to use that as a substitute for imp.load_source()/imp.load_module(). I'm going to leave this bug open, hijack its title, and refocus this as to consider leaving importlib.abc.Loader.load_module() in importlib as the all-powerful fallback API which also simplifies transitioning from imp. |
I'd rather see something like "load_from_spec()" added to importlib.util, a la issue bpo-21235. |
Python 3.5 lets you do: spec = importlib.util.spec_from_file_location('what.ever', 'foo.py')
module = importlib.util.module_from_spec(spec)
spec.loader.exec_module(module) I am satisfied that case for loading from a file is easy enough to not warrant keeping load_module() around just for this use case. |
I would ask you to reconsider this. https://stackoverflow.com/questions/67631/how-to-import-a-module-given-the-full-path/67692#67692 is a highly active question on StackOverflow, and my answer basically provided me all the karma I got there. For users that don't have intimate insight in how importlib works, the code posted by Brett is completely non-obvious and I believe that a convenience method would be very useful. |
FWIW, I think it would be desirable to retain/restore some form of API that allows the creation of modules from files without requiring the user to know about module specs (or loaders, or anything else). My current preference would be for a "module_from_file_location" counterpart to "spec_from_file_location" that implements Brett's recipe from above. That code is visually short, but conceptually very dense,and hence far from being obvious to most people trying to make the "path to module" leap. Such a function could also cross-reference runpy.run_path for cases where don't want a module at all, just the top level namespace. |
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: