Re: PEP 420 issue: extend_path

On 05/07/2012 04:38 AM, "Martin v. Löwis" wrote:
> I'd like to propose that pkgutil.extend_path is specified to also
> consider portions according to the PEP. Currently, it will only
> consider portions having an __init__.py
> 
> If a namespace package gets a portion installed that has an __init__.py,
> then all existing portions become ignored under
> the current PEP. With that change, if a portion has an __init__.py
> that uses extend_path, the other portions would still be considered.
> 
> With the current PEP, all contributors to a package need to
> simultaneously agree to drop their __init__.py for 3.3. Initially,
> this could cause confusion, and hinder adoption of the PEP.
> 
> The same would also apply to pkg_resources.declare_namespace.
> Unfortunately, this is out of the scope of the PEP, but I'm sure Tarek
> would accept a patch to distribute to bring it into conformance to
> pkgutil.

I agree this is an important consideration. I haven't had time to think
it through, yet.

> Interestingly, it appears that pkg_util will break under PEP 420,
> anyway, as it currently does (in _handle_ns)
> 
>     loader = importer.find_module(packageName)
>     if loader is None:
>         return None
> ...
>         loader.load_module(packageName); module.__path__ = path
> 
> Now, if loader suddenly becomes a string, than the load_module
> call will raise an attribute error (untested).

I've become convinced that we need a new finder method, and leave
find_module with its current (3.2) semantics.

Eric.