Re: pkgutil.extend_path

On Tue, May 15, 2012 at 1:26 PM, Eric V. Smith <[email protected]> wrote:

> I'm looking at fixing pkgutil.extend_path in order to support namespace
> packages where some portions use PEP-420 and some use extend_path.
>
> The first thing I notice is that there are no tests for
> pkgutil.extend_path :(
>
> extend_path currently just examines the filesystem directly, which means
> it doesn't support portions in zip files or other finder/loaders.
>
> But if I understand PJE and others correctly, the idea is to modify
> extend_path so it calls the path_hook finders instead of looking at the
> filesystem (in order to find the other __path__ entries).


Well, I actually wasn't trying to support that at all; I've never used
extend_path() myself, so I was only talking about implementing transitional
support for the PEP in declare_namespace().

That being said, it sounds like adding support in extend_path() might also
be worthwhile.  Presumably, it would *not* auto-update, since extend_path()
doesn't currently do that.  (Just as declare_namespace() *should*
auto-update, because it currently does.)



> This looks
> like a change in functionality: previously only real filesystem packages
> would be found. With this change it would include other finders (like
> zip files). While it's a change, it would align well with importlib.
> Personally I'm okay with this change.
>

Makes sense to me.

There's the added issue of how to deal with .pkg files. Is only
> supporting them from the filesystem okay? Or is it worth the hassle of
> creating some finder API to access them?
>

I don't know who actually uses them, but then I don't know who uses
extend_path(), period.  The only examples I was able to find with Google
and Nullege are of the form "try: declare_namespace() except:
extend_path()" -- that is, code that first tries to use declare_namespace()
instead.

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