[Zope3-dev] Packaging conventions (was Re: PyCon DC 2003: Call For Papers)

[Phillip J. Eby]

At 11:11 AM 12/5/02 -0500, Stephan Richter wrote:
>On Thursday 05 December 2002 11:06, Phillip J. Eby wrote:
> > The only addition to this that we do in PEAK, is that there *is* an "api"
> > module in major packages, but it imports selected classes and functions
> > from the rest of the package.  It's designed to be used like this:
> >
> > from peak.naming import api as naming
> >
> > naming.lookup('something')
>
>I think this is similar to Shane's public.py.

It solves the same sort of problem, but I don't think "public" is the right 
name for use in a framework like Zope.  It seems to imply that the rest of 
the package is therefore "private".  If that is truly the case for a 
particular package (such as Shane's Jobboard example), then I agree that 
"public" makes sense.

But I think that most framework packages in systems like Zope and PEAK are 
not really "public vs. private", but rather "user vs extender", and thus an 
"API" versus "stuff you'll only need if you want to extend the 
framework".  Things in a framework that are really and truly private 
shouldn't be listed in their module's "__all__", and should probably be 
marked with dire warnings in their docstrings as well.  :)