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

[Stephan Richter]

On Thursday 05 December 2002 08:41, Guido van Rossum wrote:
> - Module and package names should be short and lowercase.  Motivation:
>   you'll never again confuse a class with its module.

I like that.

> - Modules should contain more than one class (a rule designed to be
>   broken :-).  Motivation: this way the presentation order of classes
>   (whether top-down or bottom-up) can help the reader to understand
>   what's important; and it clarifies what classes (or functions) are
>   related.  Compare to trying to find where to start in a directory
>   full of classes, listed alphabetically.

That has another advantage: You do not have to write the name twice in the 
import. Right now we often have: from package.ClassName import ClassName

> - Special case: all interfaces go in "interfaces.py".  Motivation: see
>   previous bullet.  (We tried thinking of a shorter name, but rejected
>   abbrevs and "api.py" is wrong, since quite often several interfaceds
>   are more internal than part of the API.  Also it's still an abbrev,
>   even if a very common one.)

I really like this idea: from package.interfaces import IFace looks really 
good to me.

> - Since the above rules greatly reduce the number of files, there's
>   much less need to create subdirectories for certain classes of
>   files.  In particular, it seems that views can happily live in the
>   main package directory, rather than in a subdirectory named by
>   category (e.g. "browser").  

Mmhh...

> (Note that we already decided not to group all views in a "views" 
subdirectory.)  

Yep. I am for that now.

> I imagine that if a
>   product has a large number of e.g. images or ZPT templates, they
>   could still go into a separate subdirectory, at the product
>   designer's discretion, but if you have just a few, that's not
>   required.  I found that having only one configure.zcml for a project
>   rather than a main one and one for "browser" related configuration
>   reduces the amount of configuration boilerplate (there's enough of
>   that already :-).

Good reasoning here. I like it.

> > Mmh, in my opinion it is not just burocracy; I usually start at the
> > original proposal of a feature, when I try to write documentation
> > for it, since the proposal usually discusses the motivation and
> > shortcomings of the feature (for example), which is always helpful
> > when writing docu.
>
> We used the shortcut of having several people in the same room
> discussing the project.  This works quite well as long as you write
> things down afterwards.

Yep, I agree as long as you write it down somewhen. :-)

> Well, you can't avoid people abandoning projects. :-(  I doubt they
> would have done better if forced to document what they did. :-(

"Better" is not the point. If they document what they are doing, then I (for 
example) can pickup a project much easier or simply know where to continue. 
It also might help later sprint teams.

> > I guess we do not need so much a proposal than a Sprint log...
>
> Last night I wrote several pages of diary about my project so far (the
> text index).  I can purge it of personal remarks and post it here, or
> on the website.  It would take me an hour to edit probably.  Is that
> worth it?

Yes! I think it would be very valuable, especially since I do not know much 
about this topic. I wish every group would do that...

I think posting it on the Wiki would be fine. I could start a new SubProject 
called IndexingAndSearching (or just make a better suggestion) for you guys 
in the Zope3 Wikis, where you could place the notes. 

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training