[Python-Dev] PEP 382: Namespace Packages

P.J. Eby pje at telecommunity.com
Tue Apr 14 18:27:51 CEST 2009

At 05:02 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
>I don't see the emphasis in the PEP on Linux distribution support and the
>remote possibility of them wanting to combine separate packages back
>into one package as good argument for adding yet another separate hierarchy
>of special files which Python scans during imports.
>That said, note that most distributions actually take the other route:
>they try to split up larger packages into smaller ones, so the argument
>becomes even weaker.

I think you've misunderstood something about the use case.  System 
packaging tools don't like separate packages to contain the *same 
file*.  That means that they *can't* split a larger package up with 
your proposal, because every one of those packages would have to 
contain a __pkg__.py -- and thus be in conflict with each 
other.  Either that, or they would have to make a separate system 
package containing *only* the __pkg__.py, and then make all packages 
using the namespace depend on it -- which is more work and requires 
greater co-ordination among packagers.

Allowing each system package to contain its own .pkg or .nsp or 
whatever files, on the other hand, allows each system package to be 
built independently, without conflict between contents (i.e., having 
the same file), and without requiring a special pseudo-package to 
contain the additional file.

Also, executing multiple __pkg__.py files means that when multiple 
system packages are installed to site-packages, only one of them 
could possibly be executed.  (Note that, even though the system 
packages themselves are not "combined", in practice they will all be 
installed to the same directory, i.e., site-packages or the platform 
equivalent thereof.)

More information about the Python-Dev mailing list