"namespace" vs "module" packages (was Re: [Zope3-dev] packaging conventions note)
Jim Fulton
jim@zope.com
Fri, 13 Dec 2002 16:44:13 -0500
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