[Python-Dev] PEP 382: Namespace Packages

[P.J. Eby]

At 03:58 AM 4/17/2009 +0000, glyph at divmod.com wrote:
>Just as a use-case: would the Java "com.*" namespace be an example 
>of a "pure package with no base"?  i.e. lots of projects are in it, 
>but no project owns it?

Er, I suppose.  I was thinking more of the various 'com.foo' and 
'org.bar' packages as being the pure namespaces in question.  For 
Python, a "flat is better than nested" approach seems fine at the moment.


>Just to clarify things on my end: "namespace package" to *me* means 
>"package with modules provided from multiple distributions (the 
>distutils term)".  The definition provided by the PEP, that a 
>package is spread over multiple directories on disk, seems like an 
>implementation detail.

Agreed.


>Entries on __path__ slow down import, so my understanding of the 
>platonic ideal of a system python installation is one which has a 
>single directory where all packages reside, and a set of metadata 
>off to the side explaining which files belong to which distributions 
>so they can be uninstalled by a package manager.

True... except that part of the function of the PEP is to ensure that 
if you install those separately-distributed modules to the same 
directory, it still needs to work as a package and not have any 
inter-package file conflicts.


>Of course, for a development installation, easy uninstallation and 
>quick swapping between different versions of relevant dependencies 
>is more important than good import performance.  So in that case, 
>you would want to optimize differently by having all of your 
>distributions installed into separate directories, with a long 
>PYTHONPATH or lots of .pth files to point at them.
>
>And of course you may want a hybrid of the two.

Yep.


>So another clarification I'd like in the PEP is an explanation of 
>motivation.  For example, it comes as a complete surprise to me that 
>the expectation of namespace packages was to provide only 
>single-source namespaces like zope.*, peak.*, twisted.*.  As I 
>mentioned above, I implicitly thought this was more for com.*, 
>twisted.plugins.*.

Well, aside from twisted.plugins, I wasn't aware of anybody in Python 
doing that...  and as I described, I never really interpreted that 
through the lens of "namespace package" vs. "plugin finding".


>Right now it just says that it's a package which resides in multiple 
>directories, and it's not made clear why that's a desirable feature.

Good point; perhaps you can suggest some wording on these matters to Martin?


>Okay.  So what I'm hearing is that Twisted should happily continue 
>using our own wacky __path__-calculation logic for twisted.plugins, 
>but that *twisted* should be a namespace package so that our 
>separate distributions (TwistedCore, TwistedWeb, TwistedConch, et. 
>al.) can be installed into separate directories.

Yes.

Thanks for taking the time to participate in this and add another 
viewpoint to the mix, not to mention clarifying some areas where the 
PEP could be clearer.