This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author aronacher
Recipients aronacher
Date 2014-04-15.14:24:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za>
In-reply-to
Content
3.4 deprecates load_module on the loaders and now proposes to use create_module (optionally) and exec_module.  Unfortunately for external callers these interfaces are not useful because you need to reimplement _SpecMethods.create and a whole bunch of other stuff for it.

Right now a caller can get hold of _SpecMethods by importing from _frozen_importlib but that seems very unsupported and is obviously entirely not exposed.

Is there a reason those methods are not on the ModuleSpec directly but on a private wrapper?

Example usage:

from types import ModuleType
from importlib.machinery import ModuleSpec, SourceFileLoader
from _frozen_importlib import _SpecMethods

loader = SourceFileLoader('plugin_base', 'my_file.py')
spec = ModuleSpec(name=loader.name, loader=loader)
mod = _SpecMethods(spec).create()

In the absence of _SpecMethods a caller needs to do this:

from importlib.machinery import ModuleSpec, SourceFileLoader

loader = SourceFileLoader('plugin_base', 'my_file.py')
spec = ModuleSpec(name=loader.name, loader=loader)
if not hasattr(loader, 'create_module'):
    module = types.ModuleType(loader.name)
else:
    module = loader.create_module(spec)
module.__loader__ = loader
module.__spec__ = spec
try:
    module.__package__ = spec.parent
except AttributeError:
    pass
loader.exec_module(module)

(And that is not the whole logic yet)
History
Date User Action Args
2014-04-15 14:24:41aronachersetrecipients: + aronacher
2014-04-15 14:24:41aronachersetmessageid: <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za>
2014-04-15 14:24:41aronacherlinkissue21235 messages
2014-04-15 14:24:40aronachercreate