Eric Snow added the comment: I agree that this is something we need to address in 3.5. Adding this to 3.4 won't be an option since it would require a new feature. However, Loader.load_module() is only deprecated (and won't be removed in 3.X), so the current approach will still work until we provide a new approach in 3.5. The only gap is that now it is possible (even if very unlikely) that in 3.4 you would run into a loader that does not implement load_module(), which would obviously break direct calls to the method. :(
For 3.4 such direct calls in the stdlib to loader.load_module() were replaced with this (mostly): spec = importlib.util.spec_from_loader(name, loader) # or importlib.util.spec_from_file_location(...) methods = _SpecMethods(spec) mod = methods.load() As you already noted, this relies on a current implementation detail of importlib._bootstrap. We'd rather not encourage use of such private API so providing a simple replacement makes sense. Futhermore, for 3.5 (in the "soon" timeframe) I'm planning on working on improving the import system abstractions*. My expectation is that part of that will be exposing most or all of the functionality of _SpecMethods directly. At the same time I don't want that API to be a distraction. I think accomplishing both is doable. So you shouldn't need to worry about create() or anything else. * Suggestions welcome. :) You can email me directly (ericsnowcurren...@gmail.com). ---------- components: +Library (Lib) nosy: +brett.cannon, eric.snow, ncoghlan versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21235> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
