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