<div class="gmail_quote">On Fri, May 11, 2012 at 12:58 PM, Eric V. Smith <span dir="ltr"><<a href="mailto:eric@trueblade.com" target="_blank">eric@trueblade.com</a>></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>
> On 05/11/2012 08:54 AM, Eric V. Smith wrote:<br>
>> I think something along the lines of PJE's approach described in<br>
>> <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>
>> doable. I think it's somewhat more complex because you need to call<br>
>> finders to do the path computation, plus there's a cache involved, etc.<br>
>><br>
>> I'd be willing to consider include this in the PEP, but I've run out of<br>
>> time to prove it's feasible by implementing it in the features/pep-420<br>
>> branch. If anyone else has time, that would be great.<br>
><br>
> Nevermind. I created some spare time and got it working. I'll update the<br>
> PEP and the pep-420 branch sometime today.<br>
<br>
</div>I'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 "Has a <tt class="docutils literal">__path__</tt> attribute set to the list of directories that
were found and recorded during the scan." but this should be changed to say it'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's just this other bit that needs to be clear. Maybe a section called "Differences Between Namespace Pacakges And Regular Packages" 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's already mentioned, but it's mentioned as rejected, when in fact the main difference between 402 and 420 is that we'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't about credit - I'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>