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

[Jim Fulton]

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.

No, but instead, you have a ".public" burnt offering.


> - 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 ;-) )

This isn't an advantage. You are just asserting that the cost is low.


> - 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

I'd rather:

   from jobboard import JobBoard

This requires making JobBoard available in __init__, which I don't
think is bad in this example.  I'll say more about __init__ in a later
example.

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