[Zope3-dev] packaging conventions note

[Shane Hathaway]

Guido van Rossum wrote:
>>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.
> 
> 
> The new naming conventions make it possible once again to stick some
> small amount of code in __init__.py that exports the piblic classes.
> Previously, this was problematic because the class name and the module
> name were often the same.  No more.  So I'm -1 on public.py now --
> __init__.py will do just fine.  (As long as you don't use import *. :-)

The downside is that then it's harder to find classes whose name you 
know but not their module.  I don't like the idea of requiring module 
names to be short and lowercase.  I do like the idea of package names 
being short and lowercase, OTOH.

Java's convention of naming the module the same as the class is a big 
advantage for navigating lots of code.  You rarely have to guess where a 
class is located.  (Just look at Twisted.  If you want to find the 
"TwistedSocketNotifier" class, would you know to look in "qternet.py" 
without using grep?)  Unfortunately, as you know, that convention 
clashes with Python's __init__.py, resulting in names being obscured.

public.py / api.py provide a way to name the module and the class the 
same without the problems associated with doing so.  But since it's 
possible to drop a public.py into any package without disturbing it, the 
real question is whether we *require* people to name their modules 
differently from their classes.  You're suggesting that we make such a 
requirement, but it seems harsh.  It's hard to guess at someone else's 
abbreviations.

Shane