ZODB now supports user-defined __get/set/delattr__ methods
I've just checked in some changes to ExtensionClass, and ZODB in the Zope CVS tree that provide support for user-defined (python) __get/set/delattr__ methods. These methods now have the same semantics as they do in standard Python classes. This means that you can define your own __get/set/delattr__ hooks and they will automatically work with, rather than break, the persistence system's use of the low-level attribute hooks. These changes are available in the Zope public CVS and will be available in future Zope releases, including 2.2 and it's beta releases. The changes are not in the 2.2 alpha1 release. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
At 02:02 PM 5/16/00 -0400, Jim Fulton wrote:
I've just checked in some changes to ExtensionClass, and ZODB in the Zope CVS tree that provide support for user-defined (python) __get/set/delattr__ methods. These methods now have the same semantics as they do in standard Python classes.
This means that you can define your own __get/set/delattr__ hooks and they will automatically work with, rather than break, the persistence system's use of the low-level attribute hooks.
[roar of applause]
These changes are available in the Zope public CVS and will be available in future Zope releases, including 2.2 and it's beta releases. The changes are not in the 2.2 alpha1 release.
Just out of curiosity, was this inspired by DynPersist.c as released in ZPatterns 0.3.0 the week before last? I can see that your solution to the problem goes much deeper than just getting attr hooks for persistence as my simple hack did. But I was just curious if perhaps you saw my hack and decided that it would be better to put it directly into the base class. Certainly it'll be better for me and for users of ZPatterns, since I'll be able to phase out DynPersist.c for Zope 2.2.
"Phillip J. Eby" wrote:
At 02:02 PM 5/16/00 -0400, Jim Fulton wrote:
(snip)
These changes are available in the Zope public CVS and will be available in future Zope releases, including 2.2 and it's beta releases. The changes are not in the 2.2 alpha1 release.
Just out of curiosity, was this inspired by DynPersist.c as released in ZPatterns 0.3.0 the week before last?
No.
I can see that your solution to the problem goes much deeper than just getting attr hooks for persistence as my simple hack did.
I saw a hack you sent me a few months ago and approved of it's intent and was saddened by it's necessity.
But I was just curious if perhaps you saw my hack and decided that it would be better to put it directly into the base class.
Actually, I wanted to solve this problem for some time. I was afraid I'd have to implement some grand unified arbitrarily chainable attr hook manager. :) The other night, I thought I wanted to use attr hooks for the database mounting experiments I've been doing. While thinking about it, I realized that there was a simple solution. I actually ended up not using the new attr support for database mounting. :)
Certainly it'll be better for me and for users of ZPatterns, since I'll be able to phase out DynPersist.c for Zope 2.2.
Yup. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Jim Fulton wrote: [snip]
The other night, I thought I wanted to use attr hooks for the database mounting experiments I've been doing. While thinking about it, I realized that there was a simple solution.
Awesome; I might want to use these for XMLWidgets. A widget is something that layers on top of an XML node and supplies it with extra methods, dynamically. In fact the way it's implemented now it acquisition-voodoos itself with __of__() *underneath* the node (in fact underneath *all* nodes, as otherwise it'd break XMLDocument's use of acquisition to get access to the parent node..). This is however slow and hackish and cumbersome. I was wishing for __getattr__ then.
I actually ended up not using the new attr support for database mounting. :)
Yes, I noticed you did something with __of__(). From an XMLWidgets point of view, I'm very interested in the techniques used here. Could you explain how it works conceptually? You seem to supply somekind of wrapper object as well, which is what I need for the widgets. Regards, Martijn
On Tue, 16 May 2000, Jim Fulton wrote:
I've just checked in some changes to ExtensionClass, and ZODB in the Zope CVS tree that provide support for user-defined (python) __get/set/delattr__ methods. These methods now have the same semantics as they do in standard Python classes.
Have you looked at my patches to allow subclassing ExtensionClasses from C? The details (along with the patch) are in the collector at: http://classic.zope.org:8080/Collector/1179/view They don't break source or binary compatibility with released versions of zope AFAIK, and having this functionality integrated into the official ExtensionClass distribution would make my life a lot easier.
These changes are available in the Zope public CVS and will be available in future Zope releases, including 2.2 and it's beta releases. The changes are not in the 2.2 alpha1 release.
Jim
James. -- Email: james@daa.com.au WWW: http://www.daa.com.au/~james/
I haven't had time to look at this. Sorry. I'd like to look at it, but I just haven't hd time. Sorry. Please feel free to nag me periodically if you wish. :) Jim James Henstridge wrote:
On Tue, 16 May 2000, Jim Fulton wrote:
I've just checked in some changes to ExtensionClass, and ZODB in the Zope CVS tree that provide support for user-defined (python) __get/set/delattr__ methods. These methods now have the same semantics as they do in standard Python classes.
Have you looked at my patches to allow subclassing ExtensionClasses from C? The details (along with the patch) are in the collector at: http://classic.zope.org:8080/Collector/1179/view
They don't break source or binary compatibility with released versions of zope AFAIK, and having this functionality integrated into the official ExtensionClass distribution would make my life a lot easier.
These changes are available in the Zope public CVS and will be available in future Zope releases, including 2.2 and it's beta releases. The changes are not in the 2.2 alpha1 release.
Jim
James.
-- Email: james@daa.com.au WWW: http://www.daa.com.au/~james/
-- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
FYI, I have found a problem with the setattr/delattr implementation. I'm not sure it's technically a bug, but if I understand the code correctly, setting or deleting a non _v_ attribute on a cPersistent will always cause the object to be marked changed, regardless of what the Python-level __set/delattr__ routine does. This seems incorrect for situations where the Python-level code is manipulating an external attribute. IMHO, the correct behavior would be to require a "persistent" __setattr__ or __delattr__ to use _p_changed directly if they are manipulating the object data. This is the algorithm used by ZPatterns, and also seems consistent with the normal semantics of having a __setattr__ or __delattr__ routine - i.e., if you implement a set/del hook, you have to implement it completely. At 02:02 PM 5/16/00 -0400, Jim Fulton wrote:
I've just checked in some changes to ExtensionClass, and ZODB in the Zope CVS tree that provide support for user-defined (python) __get/set/delattr__ methods. These methods now have the same semantics as they do in standard Python classes.
This means that you can define your own __get/set/delattr__ hooks and they will automatically work with, rather than break, the persistence system's use of the low-level attribute hooks.
"Phillip J. Eby" wrote:
FYI, I have found a problem with the setattr/delattr implementation. I'm not sure it's technically a bug,
No, it's a missfeature.
but if I understand the code correctly, setting or deleting a non _v_ attribute on a cPersistent will always cause the object to be marked changed, regardless of what the Python-level __set/delattr__ routine does. This seems incorrect for situations where the Python-level code is manipulating an external attribute. IMHO, the correct behavior would be to require a "persistent" __setattr__ or __delattr__ to use _p_changed directly if they are manipulating the object data. This is the algorithm used by ZPatterns, and also seems consistent with the normal semantics of having a __setattr__ or __delattr__ routine - i.e., if you implement a set/del hook, you have to implement it completely.
I agree. I'll change this as you described. In summary, if you override __setattr__ or __delattr__ and you change the state of the object, then it is up to you to: self._p_changed=1 or the change to the object's state will not be registered. Jim
At 02:02 PM 5/16/00 -0400, Jim Fulton wrote:
I've just checked in some changes to ExtensionClass, and ZODB in the Zope CVS tree that provide support for user-defined (python) __get/set/delattr__ methods. These methods now have the same semantics as they do in standard Python classes.
This means that you can define your own __get/set/delattr__ hooks and they will automatically work with, rather than break, the persistence system's use of the low-level attribute hooks.
-- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
participants (4)
-
James Henstridge -
Jim Fulton -
Martijn Faassen -
Phillip J. Eby