[ZODB-Dev] new-style 2.2 classes and ZODB?

Mike C. Fletcher mcfletch@geocities.com
Wed, 13 Feb 2002 03:13:09 -0500


My bad.

I asked earlier (Sunday, I think) if you could store 2.2-style classes 
in ZODB.  I was told, "No, not unless you use the Zope3 ZODB" (i.e. not 
with the current ZODB).  I checked the latest ZODB3 sources out from 
CVS, built them, and installed them on my system.  With those, 2.2-style 
classes work fine.  This is not the StandAlone ZODB package any more, of 
course, it's just a form of ZODB (hmm, just realised, this is the wrong 
list! I was intending to post to zope3-dev, not zodb-dev)

 From what I'm told, it sounds as though you could store new-style 
classes with ZODB2, you'd just need to replace the transaction and 
persistent Python package/modules with the new code (i.e. the relevant 
changes in ZODB3 are not to the underlying ZODB, but rather to the 
Persistence.Persistent class (which was previously (in ZODB2.x) an 
extensionclass instance, but with ZODB3 is just an object instance with 
some getattribute/setattribute hooks.)

I'm guessing reversing the order was just making object the "primary" 
class (the one doing the initialisation) and it didn't check to see if 
there were any bases-conflicts, whereas extensionclass probably does/did.

Sorry about the confusion, will pay more attention to what pops up in 
the address window next time I type zo...,
Mike

Kendall Clark wrote:
> Folks,
> 
> I guess I just assumed that "ZODB works with 2.2" meant that you could
> write persistent new-style classes, but maybe that's not the case?
> 
> Earlier, while trying to kill time, hoping a fix for the ZODB segfault
> I'm getting is found, I tried to write a very simple persistent
> new-style class.
> 
> The first thing I did was:
> 
> class Foo(object, Persistent):
>     pass
> 
> which gets a
> 
> TypeError: metatype conflict among bases
> 
> Okay, I think, I don't really grok the new multi-inheritance
> algorithm, but perhaps I should switch those around:
> 
> class Foo(Persistent, object):
>     pass
> 
> Bingo, no more TypeError -- I'll have to figure out why this matters
> at some point, but let's move on.
> 
> Now, let's add one simple get/set attribute to the class and try to
> persist it. So I take the exemplar class from Guido's Unifying Types
> and Classes paper:
> 
> class C(Persistent, object):
>     
>     def __init__(self):
>         self.__x = 0
>         
>     def getx(self):
>         return self.__x
>         
>     def setx(self, x):
>         if x < 0: x = 0
>         self.__x = x
> 
>     x = property(getx, setx)
> 
> if __name__ == "__main__":
> 
>     a = C()
>     a.x = 10
>     print a.x
> 
> Running "python2 C.py" gives this:
> 
> cmpu:~/forum$ python2 C.py
> Traceback (most recent call last):
>   File "C.py", line 22, in ?
>     a = C()
>   File "C.py", line 9, in __init__
>     self.__x = 0
> TypeError: function takes exactly 2 arguments (1 given)
> 
> Hmm, I have no idea what that's about, maybe there's something about
> new-style classes I don't get yet... <read for 20 minutes; play around
> with just about every __slots__, descriptors, property, staticmethod,
> classmethod combo I can think of...>
> 
> Still no luck.
> 
> So, I think, forget about persisting *new* classes, how about:
> 
> class C(Persistent):
> ...
> 
> Does that work? Yes, just as you'd expect:
> 
> cmpu:~/forum$ python2 C.py
> 10
> 
> What about a non-persistent new-style class?
> 
> Yes, that works too:
> 
> cmpu:~/forum$ python2 C.py
> 10
> 
> Either I'm missing something really obvious, or Guido's exemplar class
> doesn't like ZODB, or ZODB doesn't like it. Or maybe I read too much
> into the statement that Standalone ZODB works with Python 2.2?
> 
> Any light that can be shed is appreciated.
> 
> Kendall Clark
> --
> Jazz is only what you are. -- Louis Armstrong
...