Can I, a humble Zope product developer, please make
 a plea that anything "marked as an 'official evil'" be made
as invisible as possible?  (I.e. that you make it disappear
unless specifically configured as an option, as was
suggested up-thread).

Zope is already full of deprecated methods that make
learning the "one obvious way to do it" very hard to figure out.

The refrain on the ML and in other places is "if the
documentation isn't good enough, 'use the Source, Luke'",
but have you actually looked at the source?  Sorry, I know
you have -- but please try to imagine what it looks like to a
newcomer who doesn't know their way around like you do.

We already have same-named objects defined in multiple
places -- are they really all the same object?  Are they
different implementations of the same object?  Are they
actually just imports from one module to another?  Are
they overloaded with additional functionality?  

Also lots of similar objects -- should I use "Item" or "SimpleItem". 
Should I inherit stuff from "Globals" or from the files they are
actually defined in?

It is an important point of information architecture that
signs to the user must be graded in order to be most
useful -- many signs with the same apparent importance
are confusing, and may be worse than no signs at all.

Also, whereas you, who are intimately familiar with
evolutionary history of Zope's source may be completely
aware of what's old and what's new, the newbie developer
has little way to determine this.  I can look at file dates, and
occasionally I can find notes explaining this in the comments. 
But too often developers say something along the lines of 
"this is the new improved way to do X". But when did they
write that?  Last month?  A year ago? Longer?

I recognize that you all have made steps in this direction
for Zope 3 (such as the interface/components concept,
which IMHO is a big improvement).

Reducing confusion should be a big priority, I hope. And
what you don't say is just as good as what you do. Minimalism
seems very pythonic to me. ;-)

Just my 2 cents.


On Wednesday 04 June 2003 09:21 am, [EMAIL PROTECTED] wrote:
> If I remember correctly, though, there was still a lot in question about
> legitimate use cases.  The web-services cluster-safety use-case I sketched
> out here (
> is still (perhaps) a valid case, but ONLY in a very-carefully constructed
> application (and even that case leaves me wanting a better app-level way to
> do it).
> I think I agree with the feeling that versions should stay in ZODB, but be
> depreciated/marked as "official evil" in ZMI.
> Sean
> > -----Original Message-----
> > From: Guido van Rossum [mailto:[EMAIL PROTECTED]
> > 
> > > To anyone not following the "Problem committing  zope 
> > 'version' objects"
> > > thread on [EMAIL PROTECTED]:  It's been proposed that Versions should be
> > > at least stamped in the ZMI with big warnings, or possibly disabled
> > > altogether.  Numerous users have been bit by the fact that versions
> > > basically do not work as advertised, leading in various 
> > cases to zodb 
> > > corruption or work that can't be saved.  There are other 
> > security issues
> > > that Oliver Bleutgen raised privately which I won't state here.
> > > 
> > > Comments?  Could we get at least some warnings in the ZMI before
> > > 2.6.2 final?
> > 
> > IMO versions do nothing except complexify the code.  I believe it's an
> > official Zope Corp position to discourage them for new projects.  Yet
> > Jeremy Hylton seems to think that they are somehow useful and has
> > carefully preserved them in ZODB 4 (== Zope 3).  If it were up to me,
> > they would have been gone, with a big helping of YAGNI!
> > 
> > --Guido van Rossum (home page:

Terry Hancock ( hancock at )
Anansi Spaceworks

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to