[Zope3-dev] "Hello World" CGI surprise for zope.publisher

Phillip J. Eby pje@telecommunity.com
Mon, 14 Apr 2003 19:46:53 -0400


At 04:16 PM 4/14/03 -0400, Jeremy Hylton wrote:
>On Mon, 2003-04-14 at 15:51, Phillip J. Eby wrote:
> > At 09:03 PM 4/14/03 +0200, Steve Alexander wrote:
> >
> > >>Pop quiz: Anybody care to guess at the output of this script?  Or more
> > >>simply, anybody care to guess at how many *digits* there are in the
> > >>number of *lines* this script outputs?  How many modules would you 
> expect
> > >>to come from the 'zope' package alone?  Are you as surprised as I was?
> > >
> > >I was relieved to find nothing from zope.app
> >
> > I have to admit I was similarly relieved.  The biggest surprises for me
> > were all the 'zope.schema.*' and 'xml.*' packages.
>
>So what did it actually import?

Well, the actual list is well over 100 modules, around 70 of them from the 
zope.* space.  Here's a list of the zope.* packages, from memory off the 
top of my head:

Obvious and understandable:

zope.publisher.*
zope.exceptions.*
zope.component.*
zope.interface.*

Expected, but only because I'd already read the code, but weird because 
they don't actually do anything *useful* for the example:

zope.i18n.*     (This is the one that pulls in all the XML stuff, and 
zope.schema)
zope.proxy.*     (This is only used for zope.publisher to strip proxies with)
zope.security.*  (This gets imported because zope.proxy wants it)


This I wasn't expecting at all:
zope.schema.*


There were an average of around 8-9 modules from each of the packages 
listed above.  There were also close to 10 'xml.*' modules (including sax 
and minidom stuff), and a wide variety of other Python standard library 
modules including 'pyexpat', which like the 'xml.*' modules was surprising 
to me.

The list could be cut down considerably, with a few minor 
modifications.  For example, the zope.i18n.locales and xml.* packages 
wouldn't need to be pulled in up-front if HTTP request objects created 
their 'locale' attribute on-demand instead of upon initialization.

Initially, my reaction to the huge list of modules was dismay; it seemed as 
though Zope's reputation as a "heavyweight" app server framework wasn't 
going to change.  But on reflection, there's little on that list that I'm 
not going to end up using in any *real* application I write.  So I'm not 
*too* concerned about it, especially considering how much worse it could 
have been.

I have to say, though, so far I *really* like Zope X3 (mostly the 
top-level, non-'app' stuff, but occasionally I wish I could take bits of 
the 'app' stuff and tweak them just a bit).  There's just *tons* of really 
good stuff in there.  I realized today that at some point, in my "shop", a 
'zope.*' package tree is going to become standard equipment for our apps, 
because there's just so much reusable good stuff in there.  I occasionally 
see things in the source that make my "mental performance meter" cringe, 
but for now I'm just reminding myself over and over that CPU cycles are 
cheaper than people cycles.

Anyway, if the grand plan behind Zope 3 is to get lots of mindshare and 
branding for Zope Corp. through lots of 'from zope.something import 
usefulStuff' statements, I'd have to say it's going to work like a charm.  :)