On Fri, Oct 25, 2013 at 12:24 PM, PJ Eby <pje@telecommunity.com> wrote:
I've not really had time to review this PEP yet, but from skimming
discussion to date, the only thing I'm still worried about is whether
this will break lazy import schemes that use a module subclass that
hooks __getattribute__ and calls reload() in order to perform what's
actually an *initial* load.

Depends on how you implement it probably. I have a scheme in my head using __getattribute__ and loaders which will work with this PEP if __package__ and __loader__ are not explicitly checked after execute_module() is called, so lazy imports are not going to be fundamentally broken. Since Python 3.3 lazy loaders relying on __getattribute__ have been broken due to those __package__/__loader__ checks so this is actually going to be an improvement.
 

IOW, does anything in this proposal rely on a module object having
*any* attributes besides __name__ set at reload() time?

As it stands in Python 3.3 it requires __name__ and __loader__ be defined: http://hg.python.org/cpython/file/e2c3f638c3d0/Lib/importlib/__init__.py#l101
 
 That is, is
there an assumption that a module being reloaded has

1. Been loaded, and
2. Is being reloaded via the same location, __loader__, etc. as before?

Just 2 in terms of __loader__ since loaders have to work with or without the module already existing.
 

At least through all 2.x, reload() just uses module.__name__ to
restart the module find-and-load process, and does not assume that
__loader__ is valid in advance.

That doesn't make much sense in a post-importlib world where import makes sure that __loader__ is set (which it has since Python 3.3). Otherwise you are asking for not just a reload but a re-find as well.

As for the PEP, it will probably keep the name/loader requirement but shift it to having to be set on the spec object at __spec__. I guess you could make the argument a reload should include re-running the finder step as well, but I don't think it's worth the code tweaking to make it happen when the finder/loader steps are divided as they are.
 

(Also, if this has changed in recent Python versions independent of
this PEP, it's a backwards-compatibility break that should be
documented somewhere.)

http://bugs.python.org/issue19392

-Brett
 


On Thu, Oct 24, 2013 at 2:05 AM, Eric Snow <ericsnowcurrently@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).
> * 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
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/pje%40telecommunity.com
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org