Re: Fwd: Re: Proposal and questions about PEP 420

> This hasn't been specifically discussed. Part of the rejection of PEP
> 382 was due to dots in the names of directories, but as directory
> extensions (foo.pyp). I'm not sure if this concern would also apply to
> your proposal.

Indeed, this hasn't been proposed (actually, when I presented namespace
packages to the Berlin Python user group last week, someone proposed
that).

> Also, I'm not sure how common nested namespace packages are. I know I've
> never run across them.

Not sure you understood the proposal. With namespace packages, you 
always have nested packages, so zope.interfaces would live in a 
directory "zope.interfaces".

Apparently, Java also supports that for packages these days.

> That said, I think you should post this idea to the import-sig mailing
> list, and see what others think.

I would refuse that as the primary mechanism for namespace packages.
However, I see this as a plausible extension of PEP 420: Lookup of
a package foo.bar would look in foo.__path__ for bar/, but would also
look in sys.path for foo.bar/.

In Java, people apparently want that because they get these deeply
nested directory hiearchies (org/apache/commons/betwixt/expression).
It's apparently possible to condense this into
org.apache.commons.betwixt/expression (which isn't a shorter string,
but fewer cd commands / explorer clicks / .svn folders).

I predict that people will start using PEP 420 in the reversed-domain 
fashion also, so we eventually might end up wanting something like
this for Python. However, as it can safely be added later, there is
no hurry.

Regards,
Martin