[issue20125] We need a good replacement for direct use of load_module(), post-PEP 451

[Brett Cannon]

Brett Cannon  added the comment:

I don't think this is still needed as the importlib docs now has enough 
examples to show people how to get to get similar results with a few method 
calls.

--
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20125] We need a good replacement for direct use of load_module(), post-PEP 451

[Eric Snow]

Eric Snow added the comment:

Yeah, waiting on this until 3.5 is fine with me.  Arfrever brought it up so I 
at least wanted to track it.

--
stage:  -> needs patch
versions: +Python 3.5 -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20125] We need a good replacement for direct use of load_module(), post-PEP 451

[Brett Cannon]

Brett Cannon added the comment:

I say just be patient and wait. No need to rush this as load_module() is still 
allowed to exist and be used. And if I manage to create SpecLoader than even 
new-fangled loaders and get load_module() for free.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20125] We need a good replacement for direct use of load_module(), post-PEP 451

[Eric Snow]

Changes by Eric Snow :


--
nosy: +larry

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20125] We need a good replacement for direct use of load_module(), post-PEP 451

[Eric Snow]

New submission from Eric Snow:

In issue #19713, it came up that while PEP 451 deprecated Loader.load_module(), 
it did not provide a suitable replacement for calling it directly.  We've 
worked around this in the stdlib by making calls to private APIs, but that 
won't work so well for the community at large.

The importlib._bootstrap._SpecMethods class is one we had considered making 
public, but decided to defer that decision until people demonstrated an 
interest/need.

At this point in the 3.4 release cycle I'm not sure how much we can do about 
it.  Adding something like the following would be easy, but then we'd be stuck 
indefinitely with an API that we may just deprecate in 3.5 (a one-hit wonder), 
though that might be the lesser evil.

def load_from_spec(spec):
_spec = importlib._bootstrap._SpecMethods(spec)
return _spec.load()

Adding that as a recipe to the load_module() docs wouldn't work too well 
either, since we'd still be advocating the use of a private API as a workaround.

To be honest, I'll have to defer to Brett, Nick, et al. on this one.  They have 
the experience to know the best approach to take here.  I just haven't been in 
the majors long enough.

(Where'd Guido put the keys to that time machine?)

--
components: Library (Lib)
messages: 207326
nosy: Arfrever, brett.cannon, eric.snow, ncoghlan
priority: high
severity: normal
status: open
title: We need a good replacement for direct use of load_module(), post-PEP 451
type: enhancement
versions: Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com