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