Re: PEP 420 outstanding issues

On Fri, May 11, 2012 at 8:46 PM, Eric V. Smith <[email protected]> wrote:

> On 5/11/2012 4:11 PM, PJ Eby wrote:
>
> > If find_loader() always returned a path for a package (even
> > non-namespace packages), then this would allow virtual paths to be made
> > either inclusive or exclusive of __init__ segments.  That is, it would
> > let there be a transition period where you could explicitly declare a
> > namespace to get a mixed namespace, but by default the paths would be
> > exclusive.
> >
> > I'm not sure if anything I just said is clear without an example, so
> > I'll throw one in.  Let's say somebody's writing code that spans
> > multiple Python versions, and they want their __init__-based namespace
> > packages to work, but be forward compatible with new subpackages using
> > PEP 420 portions.  Basically, they write some code that calls
> > declare_namespace(), which then sets the module's __path__ to be an
> > "inclusive virtual" path.  This path object is similar to the current
> > virtual path object, except that it *always* uses the second
> > find_loader() return value, even if the first value returned is not
> > None.  Poof!  Instant "transitional" namespace package,
> > backward-compatible with older Python versions, and forward-compatible
> > with PEP 420.
>
> But the second value (the paths) won't include anything on the parent
> path that occurs after __init__.py is found. Or am I missing something?
>

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's
__path__ with a "mixed mode" 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't be able to add sections with __init__.py's if the finders didn't
return the paths for non-namespace packages.

In other words, this isn't about changing the PEP's normal import
algorithm, it'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.

_______________________________________________
Import-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/import-sig