pje at telecommunity.com
Wed May 16 00:04:06 CEST 2012
On Tue, May 15, 2012 at 1:26 PM, Eric V. Smith <eric at trueblade.com> 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()
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Import-SIG