[ZODB-Dev] new-style class status

John Belmonte jvb at prairienet.org
Sun Oct 19 12:22:50 EDT 2003


Tim Peters wrote:
> [John Belmonte]
> 
>>I'd like to know what the status of the zodb33-devel-branch is,
> 
> It's currently inactive within Zope Corp.  MVCC is a higher priority here.
> That in turn has been a lower priority recently than customer (read
> "paying") work.
> 
>>and to get some idea when a new-style class implementation will at
>>least be hobbling well enough for us mortals to use it.
> 
> Have you tried zodb33-devel-branch?  We released 3.3a1 from that about 3
> months ago:
> 
>     http://zope.org/Products/ZODB3.3/
> 
> Note that this requires Python 2.3 (under any version of 2.2, it will just
> segfault).  IIRC, we got one piece of feedback about it.
> 
> I don't what its future may be.  Most likely now seems that MVCC work will
> continue to take precedence, get merged into the ZODB3 trunk, and eventually
> released as 3.3 (along with scads of bugfixes accumulated on the 3.1 and 3.2
> branches).  Merging zodb33-devel-branch into the trunk "should be" the
> priority after that, according to me, but I don't set priorities here.

Thanks for the info Tim.  I did try zodb33-devel-branch after my last 
email and it's working great, although I'm too early in development to 
have anything to stress-test the system.

Of course I'm wary about having my app depend on a feature branch that 
may never make it back to the trunk.  Unfortunately, I've unwittingly 
done just that-- I didn't realize that extension class comparison 
operators were broken until after the class that used them was ingrained 
into my app.

I can see needing MVCC as well.  It seems like it would be very hard to 
verify that a program is correct if I have to worry about it making a 
bad decision due to seeing an incoherent set of database objects (that 
is, in the face of inter-object invariant violations).  Then I'm also in 
need of multiple monotonic ID generators, which doesn't look to be going 
into ZODB at all.

So I'm in for some pain because my app has bleeding-edge feature 
requirements.  But I don't see an alternative to having a ZODB with 
exactly these features, other than increasing the complexity of my 
program horribly.

> One thing we need is a reimplementation of ExtensionClass as a Python
> new-style class.  The current ExtensionClass implementation is much more
> complicated than necessary now that Python makes far fewer distinctions
> between types and classes, and seems essentially unmaintainable to me.
> ExtensionClass in some API-compatible form has to continue to survive, for
> compatibility with applications already using ExtensionClass.  I know Jim
> (Fulton) looked at this some Friday, but don't know how far he got.

Is this a precondition for having new-style classes in ZODB or is it 
independent?

Perhaps I could help keep the new-style class branch in sync as 3.3 goes 
through its milestones, so that it will be ready to go for version 3.4.

-John


-- 
http:// if   le.o  /




More information about the ZODB-Dev mailing list