[Python-Dev] PEP 451 update

[Brett Cannon]

On Thu, Oct 24, 2013 at 2:05 AM, Eric Snow <ericsnowcurrently at gmail.com>wrote:

> 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).
>

Eric's got an initial patch for this up on http://bugs.python.org/issue18864.


> * 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.
>

After reading Eric's doc patch, I realized there is one change I want to
make to the current semantics and that's not to backfill __package__ when
set to None. Since import is now going to take over the job of setting
__package__ (along with other attributes), this seems like a slight waste
of effort. It also kills (or at least complicates) having a loader which
does lazy loading since reading the attribute to see if it is None would
trigger the load before leaving the import code, thus killing any postponed
loading.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131025/0c2c8a62/attachment.html>