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

[Tim Peters]

[Chris McDonough, on POSKeyError]
>>> But it's raised in a lot of places that doesn't have access to the
>>> current transaction. :-(  Maybe worse is that it subclasses KeyError
>>> (having an except KeyError: in Zope is quite common and has heretofore
>>> been deemed "safe"), so a developer could think his code was perfect
>>> and still get hosed.

[Tim Peters]
>> Ewww -- hadn't thought of that.  So it's a doubly good thing that
>> POSKeyError is impossible <wink>.

[Chris]
> I'm not sure if you're joking or not.  I think you're not -- but the
> placement of the wink is a little ambiguous.

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.

>> I think it may be worth it if it starts with the 2.8 line.  Trying to
>> keep multiple versions healthy is a horrendous drag on making
>> improvements (like, e.g., adding savepoints, or support for multiple
>> database connections -- or even this!).

> Fair enough.  I will take a stab at stickiness for various things on a
> branch of 3.3 then... if I can find it. ;-)

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

> ...

[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>.