[Zope3-dev] PyCon DC 2003: Call For Papers

[Phillip J. Eby]

At 10:37 AM 12/5/02 -0500, Shane Hathaway wrote:

>I've been trying out a complementary convention in AdaptableStorage: all 
>public classes are available through a special module called "public". For 
>example, if I made a class JobBoard and put it in jobboard.py, located in 
>the package "jobboard", I'd put a public.py next to it that includes the 
>line "from jobboard import JobBoard".  Other packages would use this class 
>with the statement "from jobboard.public import JobBoard".  There are many 
>advantages:
>
>- The public.py module becomes the documentation for use of the package by 
>other packages.
>
>- The class name does not get repeated when other packages use the class.
>
>- You can convert any package to this convention just by adding a "public" 
>module.  It conflicts with no other conventions (unless "public" ever 
>becomes a Python keyword ;-) )
>
>- It's a lot like Java imports, but without the warts.  Hence I think it 
>is likely to help those coming from Java, as I did.  In Java you would say:
>
>import jobboard.JobBoard;
>
>In Python you would say:
>
>from jobboard.public import JobBoard

Interesting.  "public" might be a good name for packages which don't really 
have an "api"; i.e. application packages rather than framework packages.  Hm.

One nice thing about having an "api" and/or "public" module, is that it 
lets you keep __init__.py empty except for documentation, which means that 
if somebody *does* need to lift out some part of your package without 
having the whole thing import, they can do so.