[Import-SIG] Dynamic path calculation in PEP 420

[PJ Eby]

On Fri, May 11, 2012 at 12:58 PM, Eric V. Smith <eric at trueblade.com> wrote:

> On 05/11/2012 12:19 PM, Eric V. Smith wrote:
> > On 05/11/2012 08:54 AM, Eric V. Smith wrote:
> >> I think something along the lines of PJE's approach described in
> >> http://mail.python.org/pipermail/import-sig/2012-April/000473.html is
> >> doable. I think it's somewhat more complex because you need to call
> >> finders to do the path computation, plus there's a cache involved, etc.
> >>
> >> I'd be willing to consider include this in the PEP, but I've run out of
> >> time to prove it's feasible by implementing it in the features/pep-420
> >> branch. If anyone else has time, that would be great.
> >
> > Nevermind. I created some spare time and got it working. I'll update the
> > PEP and the pep-420 branch sometime today.
>
> I've updated the PEP and the pep-420 branch to support dynamic path
> computation.
>

Awesome!  This now seems a more-than-worthy replacement for PEP 402.

One nit: the PEP says a namespace package "Has a __path__ 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?

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.

(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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/import-sig/attachments/20120511/57732175/attachment-0001.html>