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
With importlib.find_loader() now implemented, imp.find_module() (and its companion, imp.load_module()) can go away and stop inflicting their bad API upon the world.
The trick, though, is fixing code that uses the API. That means pkgutil, multiprocessing.forking, modulefinder, and idlelib.EditorWindow all need to be patched to stop using imp.find_module()/load_module().
http://hg.python.org/lookup/59870239813c documents imp.find_module/load_module as deprecated w/o actually raising the deprecation. The code works fine, but the API is just crap. So in the name of ease of transition (and my own personal sanity), I didn't go full-blown deprecation. The remaining code that uses imp.find_module() in the stdlib uses the API's unique properties (e.g. executing under a different name in multiprocessing) or directly exposes the API (e.g. pkgutil and modulefinder). As for idle, I don't run the tool so I don't feel like editing the code and getting it wrong.
The modulefinder usage is directly exposed in its API as the return value of a find_module method, which makes removal a pain. Adding Thomas Heller to see what he has to say.
The pkgutil usage is in classes that have been deprecated, so don't care.
The rest should be workable and I will file separate bugs.
The modulefinder usage is directly exposed in its API as the return
value of a find_module method, which makes removal a pain. Adding
Thomas Heller to see what he has to say.
Some months ago, I have started to implement a brand-new modulefinder,
which is based on importlib. It has a different API, but the (barely)
documented API functions remain the same or could be made compatible.
The advantage against the current modulefinder is that it finds modules
in zipfiles, for example in zipped eggs.
IMO it is not yet ready for inclusion into Python 3.4, but given the
plans for the first alpha release in August I will hopefully find
time to work on it a little bit more.
Activity
brettcannon commentedon May 13, 2012
With importlib.find_loader() now implemented, imp.find_module() (and its companion, imp.load_module()) can go away and stop inflicting their bad API upon the world.
The trick, though, is fixing code that uses the API. That means pkgutil, multiprocessing.forking, modulefinder, and idlelib.EditorWindow all need to be patched to stop using imp.find_module()/load_module().
brettcannon commentedon May 13, 2012
http://hg.python.org/lookup/59870239813c documents imp.find_module/load_module as deprecated w/o actually raising the deprecation. The code works fine, but the API is just crap. So in the name of ease of transition (and my own personal sanity), I didn't go full-blown deprecation. The remaining code that uses imp.find_module() in the stdlib uses the API's unique properties (e.g. executing under a different name in multiprocessing) or directly exposes the API (e.g. pkgutil and modulefinder). As for idle, I don't run the tool so I don't feel like editing the code and getting it wrong.
brettcannon commentedon May 13, 2012
BTW, I'm leaving this issue open in case someone wants to take a stab and removing the uses of imp.find_module()/load_module() from the stdlb.
brettcannon commentedon Feb 27, 2013
Assuming issue bpo-17314 gets fixed, that leaves the following uses of imp.find_module():
Lib/idlelib/EditorWindow.py
39: """Version of imp.find_module() that handles hierarchical module names"""
45: (file, filename, descr) = imp.find_module(tgt, path)
Lib/modulefinder.py
482: return imp.find_module(name, path)
Lib/pkgutil.py
229: file, filename, etc = imp.find_module(subname, path)
Lib/test/test_imp.py
59: with imp.find_module('module_' + mod, self.test_path)[0] as fd:
64: imp.find_module('badsyntax_pep3120', path)
68: fp, filename, info = imp.find_module('module_' + mod,
77: fp, filename, info = imp.find_module("tokenize")
91: file, filename, info = imp.find_module(temp_mod_name)
147: file, filename, info = imp.find_module(temp_mod_name)
187: imp.find_module, "badsyntax_pep3120", [path])
201: x = imp.find_module("os")
213: x = imp.find_module(example)
223: fileobj, pathname, description = imp.find_module(m)
Lib/test/test_import.py
128: imp.find_module, TESTFN, ["."])
Lib/test/test_importhooks.py
118: file, filename, stuff = imp.find_module(subname, path)
brettcannon commentedon Feb 27, 2013
The remaining uses of imp.load_module() after issue bpo-17314 (which will probably all disappear as uses of imp.find_module() is removed):
Lib/idlelib/EditorWindow.py
48: module = imp.load_module(tgt, file, filename, descr)
Lib/pkgutil.py
291: mod = imp.load_module(fullname, self.file, self.filename, self.etc)
Lib/pydoc.py
47:# - imp.load_module() cannot be prevented from clobbering existing
277: module = imp.load_module(name, file, path, (ext, 'r', kind))
Lib/test/test_imp.py
155: mod = imp.load_module(temp_mod_name, file, filename, info)
203: new_os = imp.load_module("os", *x)
217: mod = imp.load_module(example, *x)
Lib/test/test_importhooks.py
132: mod = imp.load_module(fullname, self.file, self.filename, self.stuff)
brettcannon commentedon Jun 7, 2013
Current status (with test_imp stripped out):
Lib/pkgutil.py
189: file, filename, etc = imp.find_module(subname, path)
251: mod = imp.load_module(fullname, self.file, self.filename, self.etc)
Lib/pydoc.py
47:# - imp.load_module() cannot be prevented from clobbering existing
280: module = imp.load_module(name, file, path, (ext, 'r', kind))
Lib/test/test_importhooks.py
118: file, filename, stuff = imp.find_module(subname, path)
132: mod = imp.load_module(fullname, self.file, self.filename, self.stuff)
brettcannon commentedon Jun 7, 2013
The modulefinder usage is directly exposed in its API as the return value of a find_module method, which makes removal a pain. Adding Thomas Heller to see what he has to say.
The pkgutil usage is in classes that have been deprecated, so don't care.
The rest should be workable and I will file separate bugs.
theller commentedon Jun 8, 2013
Some months ago, I have started to implement a brand-new modulefinder,
which is based on importlib. It has a different API, but the (barely)
documented API functions remain the same or could be made compatible.
The advantage against the current modulefinder is that it finds modules
in zipfiles, for example in zipped eggs.
IMO it is not yet ready for inclusion into Python 3.4, but given the
plans for the first alpha release in August I will hopefully find
time to work on it a little bit more.
If someone wants to read the code, or try it out:
Modulefinder:
http://code.google.com/p/ctypes-stuff/source/browse/trunk/mf/mf4.py
Test:
http://code.google.com/p/ctypes-stuff/source/browse/trunk/mf/maketest.py
Thomas