<div class="gmail_quote">On Fri, May 11, 2012 at 12:58 PM, Eric V. Smith <span dir="ltr">&lt;<a href="mailto:eric@trueblade.com" target="_blank">eric@trueblade.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 05/11/2012 12:19 PM, Eric V. Smith wrote:<br>
&gt; On 05/11/2012 08:54 AM, Eric V. Smith wrote:<br>
&gt;&gt; I think something along the lines of PJE&#39;s approach described in<br>
&gt;&gt; <a href="http://mail.python.org/pipermail/import-sig/2012-April/000473.html" target="_blank">http://mail.python.org/pipermail/import-sig/2012-April/000473.html</a> is<br>
&gt;&gt; doable. I think it&#39;s somewhat more complex because you need to call<br>
&gt;&gt; finders to do the path computation, plus there&#39;s a cache involved, etc.<br>
&gt;&gt;<br>
&gt;&gt; I&#39;d be willing to consider include this in the PEP, but I&#39;ve run out of<br>
&gt;&gt; time to prove it&#39;s feasible by implementing it in the features/pep-420<br>
&gt;&gt; branch. If anyone else has time, that would be great.<br>
&gt;<br>
&gt; Nevermind. I created some spare time and got it working. I&#39;ll update the<br>
&gt; PEP and the pep-420 branch sometime today.<br>
<br>
</div>I&#39;ve updated the PEP and the pep-420 branch to support dynamic path<br>
computation.<br></blockquote></div><br>Awesome!  This now seems a more-than-worthy replacement for PEP 402.<br><br>One nit: the PEP says a namespace package &quot;Has a <tt class="docutils literal">__path__</tt> attribute set to the list of directories that
were found and recorded during the scan.&quot; but this should be changed to say it&#39;s set to an iterable or sequence of the strings returned by the finders.  That is, it should explicitly point out that __path__ is NOT a list for namespace packages, and instead is an automatically-updated sequence.  The actual section you have on that is fine, it&#39;s just this other bit that needs to be clear.  Maybe a section called &quot;Differences Between Namespace Pacakges And Regular Packages&quot; summarizing all the differences (no __file__, read-only updated __path__, no __init__.py, etc.) would be a good idea?<br>
<br>Also a suggestion: given the number of rationale/use-case questions that seem to keep coming up, adding a note somewhere to say that people who want to know more about rationale, use cases, alternatives considered/rejected etc., to check out PEP 402.  Yes, I know it&#39;s already mentioned, but it&#39;s mentioned as rejected, when in fact the main difference between 402 and 420 is that we&#39;ve nailed down a few things that were open-ended before, and threw out a couple of minor features/limitations (i.e. the parent .py feature and the only-importing-child packages limitation), so virtually all of the rationale and alternatives discussion applies the same to 420.<br>
<br>(To be clear, this isn&#39;t about credit - I&#39;d be just as happy (maybe more so) if you simply copy-pasted relevant bits to 420 and omitted any reference to 402.  I just hate to see the same stuff getting rehashed over and over again...  and when this is more widely publicized, it almost certainly WILL all come up again.)<br>
<br>