[ZODB-Dev] RE: [Zope-Annce] ZODB 3.2.4 release candidate 1released

[Chris McDonough]

On Mon, 2004-09-13 at 20:34, Tim Peters wrote:
> POSKeyError should be impossible.  Alas, "should be" != "is" across the time
> I've been fighting this.  Think of "<wink>" as suicide prevention in this
> context.  I never realized POSKeyError derived from KeyError, and it doesn't
> seem sane that it does.

Ah ok.  So it probably wouldn't hurt to make it sticky then, I presume?

> The good news is that branching is less painful under SVN.  The trunk is
> here:
> 
>     svn+ssh://svn.zope.org/repos/main/ZODB/trunk
> 
> Making a branch goes like this:
> 
>     svn copy svn+ssh://svn.zope.org/repos/main/ZODB/trunk \
>              svn+ssh://svn.zope.org/repos/main/ZODB/branches/chris-sticky

Got it.

> [doing persistent ops as a side effect of dict key comparison]
> > As Tres would say, that Deserves To Lose.  Pfft.  The next thing you
> > know, somebody will come along and have the unmitigated gall to use
> > *hasattr*. ;-)
> 
> Python strives to be bulletproof, and has a mountain of code trying to
> protect itself from "Deserves To Lose" operations.  In part that's to guard
> against hostile users.  It takes years to get that right, though, and
> everyone has to have a clear model of exactly what Python intends to
> guarantee in extreme cases.  I'm not sure how many people have contributed
> to Zope and ZODB, but I detect subtle <heh> signs in the code that no two
> contributors ever agreed on endcase semantics.  Calling something "Deserves
> To Lose" is convenient, but also a way to ensure semantics stay fuzzy.  "Oh,
> geez, I sure don't want to think about that case!" -- "OK, on to next one
> then" <0.9 wink>.

Whew, thankfully *I* never behave like that. ;-)

- C