Re: PEP 420 issue: extend_path

Nick Coghlan <[email protected]>
Newsgroups gmane.comp.python.import
Message-ID <CADiSq7cfiLiNambzf6QCA9Qj0B+e8xL5qHunsUnzVoYBc7EW7Q@mail.gmail.com>
On Mon, May 7, 2012 at 6:38 PM, "Martin v. Löwis" <[email protected]> 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.

+1 (both on the change and on PEP 420 stating it explicitly)

> 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).

Yes, the PEP 420 implementation should definitely add some new pkgutil
tests to make sure the various utility functions either work, or at
least fail with an intelligible error message, when handed a namespace
package.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.