On Fri, May 11, 2012 at 8:46 PM, Eric V. Smith <span dir="ltr">&lt;<a href="mailto:eric@trueblade.com" target="_blank">eric@trueblade.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 5/11/2012 4:11 PM, PJ Eby wrote:<br>
<br>
&gt; If find_loader() always returned a path for a package (even<br>
&gt; non-namespace packages), then this would allow virtual paths to be made<br>
&gt; either inclusive or exclusive of __init__ segments.  That is, it would<br>
&gt; let there be a transition period where you could explicitly declare a<br>
&gt; namespace to get a mixed namespace, but by default the paths would be<br>
&gt; exclusive.<br>
&gt;<br>
&gt; I&#39;m not sure if anything I just said is clear without an example, so<br>
&gt; I&#39;ll throw one in.  Let&#39;s say somebody&#39;s writing code that spans<br>
&gt; multiple Python versions, and they want their __init__-based namespace<br>
&gt; packages to work, but be forward compatible with new subpackages using<br>
&gt; PEP 420 portions.  Basically, they write some code that calls<br>
&gt; declare_namespace(), which then sets the module&#39;s __path__ to be an<br>
&gt; &quot;inclusive virtual&quot; path.  This path object is similar to the current<br>
&gt; virtual path object, except that it *always* uses the second<br>
&gt; find_loader() return value, even if the first value returned is not<br>
&gt; None.  Poof!  Instant &quot;transitional&quot; namespace package,<br>
&gt; backward-compatible with older Python versions, and forward-compatible<br>
&gt; with PEP 420.<br>
<br>
</div>But the second value (the paths) won&#39;t include anything on the parent<br>
path that occurs after __init__.py is found. Or am I missing something?<br></blockquote><div><br>What this is for is for __init__.py files that call declare_namespace() or some other API.  When they call it, the API will replace the package&#39;s __path__ with a &quot;mixed mode&quot; virtual path object.  This object would take the parent package __path__, and walk it to find *all* the subpaths, and support auto-updates if the parent __path__ or sys.path is modified.  The reason for changing the protocol is that this alternate implementation wouldn&#39;t be able to add sections with __init__.py&#39;s if the finders didn&#39;t return the paths for non-namespace packages.<br>
<br>In other words, this isn&#39;t about changing the PEP&#39;s normal import algorithm, it&#39;s just for tools that want to provide a compatibility upgrade path, so that existing __init__.py modules can play in the new, post-PEP 420 world.<br>
<br><br></div></div>