"namespace" vs "module" packages (was Re: [Zope3-dev] packaging conventions note)

[Jim Fulton]

Tres Seaver wrote:
> On Fri, 2002-12-06 at 09:59, Guido van Rossum wrote:
> 
...


>>>Really? Jim, why not? I think it solves some problems and the fect
>>>that some independent people do this, shows that it is a good
>>>thought. I like the public.py idea. +1 from my part.
>>>
>>-1 on anything that recommends (or even facilitates) import *.  As the
>>reader of a module, import * sucks: when I see a name I don't
>>recognize, I want to be able to search the module for the first
>>definition.

Yup. Exactly..


> 
> -1 as well:  I don't even use it for the canonical example ('from
> Tkinter import *'), as I can't live with the namespace pollution issues
> (the Tkinter package doesn't mangle its public names).

Yes.


> I actually like exporting the public names from package scope, e.g.,
> 'from some_package import MyClass' gives you the class itself.  My
> rationale is that the name of the  module declaring the class is
> declared in is an implementation detail *to the clients of the packge.*
> I would find 'from some_package.public import Foo' a reasonable
> compromise with those who prefer to have the package's __init__ be
> empty.

I don't see much point in "public".

I suggest the following rational for thinking about packages:

Most packages are like modules.  Their contents are highly
interdependent and can't be pulled apart.  I think it's fine for such
packages to export names in their __init__, as long as these names
don't conflict with package module or subpackage names.  Sometimes, a
package starts out as a module that is turned into a package when it
becomes too big.  It's important that we don't need to refactor all
imports when regular modules are converted to packages.

Some packages exist to provide a separate namespace.  The Zope (zope)
and ZopeProducts (zopeproducts) packages are like this.  Namespace
packages should not export any names from their __init__ modules.  It
should be possible to distribute sub-packages or submodules of these
independently.  I would even say that namespace packages should allow
themselves to be spread over multiple physical locations.  For
example, I want the zope and zopeproducts packages to have an __init__
that arranges for all zope and zopeproducts directories found on the
Python path to be added to the respective package paths,

Jim




-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org