On Fri, Oct 25, 2013 at 12:24 PM, PJ Eby <p...@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 <ericsnowcurren...@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 >
_______________________________________________ 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/archive%40mail-archive.com
