[Import-SIG] PEP 420 issue: extend_path
Eric V. Smith
eric at trueblade.com
Tue May 8 06:52:05 CEST 2012
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
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.
More information about the Import-SIG