[Python-Dev] Implementing PEP 382, Namespace Packages

[P.J. Eby]

At 05:59 PM 5/30/2010 -0700, Brett Cannon wrote:
>Is it wise to modify __path__ post-import? Today people can make sure
>that __path__ is set to what they want before potentially reading it
>in their __init__ module by making the pkgutil.extend_path() call
>first. This would actually defer to after the import and thus not
>allow any __init__ code to rely on what __path__ eventually becomes.

Well, that's what the other lines in the .pth files are for.  Keep in 
mind that only *one* project can contain the namespace package's 
__init__ module, so it's only sane for that __init__ to import things 
that are bundled with the __init__ module.

AFAIK, most uses of namespace packages today are via setuptools' API, 
which doesn't support having a non-empty __init__.py at all (apart 
from the namespace declaration), so this limitation is unlikely to 
cause problems in practice.

When the code I gave is refactored into a proper importer/loader 
pair, it can actually be structured such that the full __path__ is 
set *before* the low-level loader is called; however, if the loader 
itself chooses to overwrite __path__ at that point, there's little 
that can be done about it.

In the Python 3.x case, the loader protocol could be revised to 
require only *adding* a non-duplicate entry to __path__ if it's 
present, and the stdlib loaders updated accordingly.  For my 
backport, OTOH, I'd have to do some sort of workaround to wrap the 
regular importers, so I'd just as soon leave it undefined by PEP 382 
what an __init__ module sees in __path__ during its execution.  (And 
for a backport whose sole purpose is to cut down on setuptools' funky 
.pth manipulations, that might suffice anyway.)