[Python-Dev] PEP 382: Namespace Packages (original) (raw)

P.J. Eby pje at telecommunity.com
Fri Apr 17 06:56:39 CEST 2009

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.

More information about the Python-Dev mailing list