<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Oct 24, 2013 at 2:05 AM, Eric Snow <span dir="ltr"><<a href="mailto:ericsnowcurrently@gmail.com" target="_blank">ericsnowcurrently@gmail.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 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></blockquote><div><br></div><div>Eric's got an initial patch for this up on <a href="http://bugs.python.org/issue18864">http://bugs.python.org/issue18864</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">


* 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></blockquote><div><br></div><div>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.</div>

</div></div></div>