[Python-Dev] PEP 451 update
Eric Snow
ericsnowcurrently at gmail.com
Thu Oct 24 08:05:10 CEST 2013
I've had some offline discussion with Brett and Nick about PEP 451
which has led to some meaningful clarifications in the PEP. In the
interest of pulling further discussions back onto this
(archived/public) list, here's an update of what we'd discussed and
where things are at. :)
* path entry finders indicate that they found part of a possible
namespace package by returning a spec with no loader set (but with
submodule_search_locations set). Brett wanted some clarification on
this.
* The name/path signature and attributes of file-based finders in
importlib will no longer be changing. Brett had some suggestions on
the proposed change and it became clear that the the change was
actually pointless.
* I've asserted that there shouldn't be much difficulty in adjusting
pkgutil and other modules to work with ModuleSpec.
* Brett asked for clarification on whether the "load()" example from
the PEP would be realized implicitly by the import machinery or
explicitly as a method on ModuleSpec. This has bearing on the ability
of finders to return instances of ModuleSpec subclasses or even
ModuleSpec-like objects (a la duck typing). The answer is the it will
not be a method on ModuleSpec, so it is effectively just part of the
general import system implementation. Finders may return any object
that provides the attributes of ModuleSpec. I will be updating the
PEP to make these points clear.
* Nick suggested writing a draft patch for the language reference
changes (the import page). Such a patch will be a pretty good
indicator of the impact of PEP 451 on the import system and should
highlight any design flaws in the API. This is on my to-do list
(hopefully by tomorrow).
* Nick also suggested moving all ModuleSpec methods to a separate
class that will simply make use of a separate, existing ModuleSpec
instance. This will help address several issues, particularly by
relaxing the constraints on what finders can return, but also by
avoiding the unnecessary exposure of the methods via every
module.__spec__. I plan on going with this, but currently am trying
out the change to see if there are any problems I've missed. Once I
feel good about it I'll update the PEP.
That about sums up our discussions. I have a couple of outstanding
updates to the PEP to make when I get a chance, as well as putting up
a language reference patch for review.
-eric
More information about the Python-Dev
mailing list