[Import-SIG] Where to discuss PEP 382 vs. PEP 402 (namespace packages)?
ncoghlan at gmail.com
Mon Mar 12 01:58:01 CET 2012
On Mon, Mar 12, 2012 at 9:02 AM, Guido van Rossum <guido at python.org> wrote:
> Martin has asked me to decide on PEP 382 vs. PEP 402 (namespace
> packages) in time for inclusion of the decision in Python 3.3. As
> people who attended the language-sig know, I am leaning towards PEP
> 402 but I admit that at this point I don't have enough information. If
> I have questions, should I be asking them on the import-sig or on
I agree with the others that import-sig is the right place.
> Is it tolerable if I ask questions even if the answer is
> somewhere in the archives? (I spent a lot of time reviewing the
> "pitchfork thread",
> but that wasn't particularly fruitful, so I'm worried I'd just waste
> my time browsing the archives -- if the PEP authors did their jobs
> well the PEPs should include summaries of the discussion anyways.)
When PJE first proposed PEP 402 I was a fan, but I changed my mind
once I realised it was fundamentally incompatible with PEP 395 (where
I want to fix the way we initialise sys.path so that direct
execution of modules inside packages isn't broken).
With the status quo or PEP 382's explicit namespace packages, the
interpreter can look at the *filesystem* to figure out where the root
directory of the package lives, as the explicit package markers (i.e.
__init__.py files or *.pyp extensions) mean there is an unambiguous
1:1 mapping from a filesystem path to a (sys.path entry, module
With PEP 402, however, the filesystem layout becomes ambigous - you
*can't* derive the appropriate sys.path entry from the filesystem any
more, because the meaning of the filesystem layout *depends on* what
you put in sys.path.
To give a simple example:
Clearly, "myproject" is a Python package with "myproject.module" and
"myproject.tests.test_module" as the contents. Only the parent
directory of "myproject" should be placed on sys.path. The package can
be executed as a script via "python -m myproject".
No real change from the status quo - the "__init__.py" marker files
are simply replaced by the "*.pyp" marker extension.
Uh-oh, now we have a problem. This is either an executable directory
(designed to be run as "python myproject" and providing a top-level
"module" and "tests.test_module") or an executable package (designed
to be run as "python -m myproject" and providing "myproject.module"
and "myproject.tests.test_module"). Because the filesystem layout is
ambiguous, there's no way for the interpreter to figure out what the
developer meant and we'd be stuck with the current broken* sys.path
I've described the implications of the two namespace PEPs briefly in
PEP 395, which also has links to the relevant import-sig threads:
*PEP 395 also explains my rationale for calling our current
sys.path initialisation mechanism broken:
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Import-SIG