[Zope3-dev] packaging conventions note

[Barry A. Warsaw]

>>>>> "SH" == Shane Hathaway <shane@zope.com> writes:

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

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

I'm with you Shane, for exactly that reason.  I've used module-name-
is-class-name convention for both the email package and Mailman and I
really like it.  I'm also with you on the short, lowercase package
name (although Mailman doesn't use this mostly for historical
reasons).

As for centralized documentation about how all the classes fit
together, well, that can /still/ go in __init__.py if you want, or it
can just go in some .tex or .txt file.
    
    SH> Unfortunately, as you know, that convention clashes
    SH> with Python's __init__.py, resulting in names being obscured.

Can you be more specific about clashes?  "from email.Parser import
Parser" works just fine.

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

I'm -1 on such a requirement, but I doubt it would be required.
Whatever the Zope Pope decides is right for Zope is fine with me too.
If I can adapt <> style to != style, I can adapt to local naming
conventions. :)

-Barry