<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Oct 25, 2013 at 12:24 PM, PJ Eby <span dir="ltr"><<a href="mailto:pje@telecommunity.com" target="_blank">pje@telecommunity.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I've not really had time to review this PEP yet, but from skimming<br>
discussion to date, the only thing I'm still worried about is whether<br>
this will break lazy import schemes that use a module subclass that<br>
hooks __getattribute__ and calls reload() in order to perform what's<br>
actually an *initial* load.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
IOW, does anything in this proposal rely on a module object having<br>
*any* attributes besides __name__ set at reload() time?</blockquote><div><br></div><div>As it stands in Python 3.3 it requires __name__ and __loader__ be defined: <a href="http://hg.python.org/cpython/file/e2c3f638c3d0/Lib/importlib/__init__.py#l101">http://hg.python.org/cpython/file/e2c3f638c3d0/Lib/importlib/__init__.py#l101</a></div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> That is, is<br>
there an assumption that a module being reloaded has<br>
<br>
1. Been loaded, and<br>
2. Is being reloaded via the same location, __loader__, etc. as before?<br></blockquote><div><br></div><div>Just 2 in terms of __loader__ since loaders have to work with or without the module already existing.</div><div>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
At least through all 2.x, reload() just uses module.__name__ to<br>
restart the module find-and-load process, and does not assume that<br>
__loader__ is valid in advance.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
(Also, if this has changed in recent Python versions independent of<br>
this PEP, it's a backwards-compatibility break that should be<br>
documented somewhere.)<br></blockquote><div><br></div><div><a href="http://bugs.python.org/issue19392">http://bugs.python.org/issue19392</a><br></div><div><br></div><div>-Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div class="h5"><br>
<br>
On Thu, Oct 24, 2013 at 2:05 AM, Eric Snow <<a href="mailto:ericsnowcurrently@gmail.com">ericsnowcurrently@gmail.com</a>> wrote:<br>
> I've had some offline discussion with Brett and Nick about PEP 451<br>
> which has led to some meaningful clarifications in the PEP. In the<br>
> interest of pulling further discussions back onto this<br>
> (archived/public) list, here's an update of what we'd discussed and<br>
> where things are at. :)<br>
><br>
> * path entry finders indicate that they found part of a possible<br>
> namespace package by returning a spec with no loader set (but with<br>
> submodule_search_locations set). Brett wanted some clarification on<br>
> this.<br>
> * The name/path signature and attributes of file-based finders in<br>
> importlib will no longer be changing. Brett had some suggestions on<br>
> the proposed change and it became clear that the the change was<br>
> actually pointless.<br>
> * I've asserted that there shouldn't be much difficulty in adjusting<br>
> pkgutil and other modules to work with ModuleSpec.<br>
> * Brett asked for clarification on whether the "load()" example from<br>
> the PEP would be realized implicitly by the import machinery or<br>
> explicitly as a method on ModuleSpec. This has bearing on the ability<br>
> of finders to return instances of ModuleSpec subclasses or even<br>
> ModuleSpec-like objects (a la duck typing). The answer is the it will<br>
> not be a method on ModuleSpec, so it is effectively just part of the<br>
> general import system implementation. Finders may return any object<br>
> that provides the attributes of ModuleSpec. I will be updating the<br>
> PEP to make these points clear.<br>
><br>
> * Nick suggested writing a draft patch for the language reference<br>
> changes (the import page). Such a patch will be a pretty good<br>
> indicator of the impact of PEP 451 on the import system and should<br>
> highlight any design flaws in the API. This is on my to-do list<br>
> (hopefully by tomorrow).<br>
> * Nick also suggested moving all ModuleSpec methods to a separate<br>
> class that will simply make use of a separate, existing ModuleSpec<br>
> instance. This will help address several issues, particularly by<br>
> relaxing the constraints on what finders can return, but also by<br>
> avoiding the unnecessary exposure of the methods via every<br>
> module.__spec__. I plan on going with this, but currently am trying<br>
> out the change to see if there are any problems I've missed. Once I<br>
> feel good about it I'll update the PEP.<br>
><br>
> That about sums up our discussions. I have a couple of outstanding<br>
> updates to the PEP to make when I get a chance, as well as putting up<br>
> a language reference patch for review.<br>
><br>
> -eric<br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
</div></div>> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/pje%40telecommunity.com" target="_blank">https://mail.python.org/mailman/options/python-dev/pje%40telecommunity.com</a><br>
<div class=""><div class="h5">_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/brett%40python.org" target="_blank">https://mail.python.org/mailman/options/python-dev/brett%40python.org</a><br>
</div></div></blockquote></div><br></div></div>