Message216303
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 (ericsnowcurrently@gmail.com). |
|
Date |
User |
Action |
Args |
2014-04-15 15:01:56 | eric.snow | set | recipients:
+ eric.snow, brett.cannon, ncoghlan, aronacher |
2014-04-15 15:01:56 | eric.snow | set | messageid: <1397574116.33.0.497838921579.issue21235@psf.upfronthosting.co.za> |
2014-04-15 15:01:56 | eric.snow | link | issue21235 messages |
2014-04-15 15:01:55 | eric.snow | create | |
|