On Tue, Mar 27, 2012 at 2:53 PM, Patrick Gerken <do3cc...@googlemail.com> wrote: > I found out, somewhat surprised, that __parent__ pointers are just > disguised aq_parent pointers.
Are you maybe trying to use or set __parent__ on Acquisition wrappers instead of unwrapped objects? AQ wrappers have various attributes, among those aq_parent and __parent__ being the same thing. If you store an actual __parent__ attribute on a "real" object, you should make sure to not wrap it in an Acquisition context or explicitly unwrap it before we Acquisition.aq_base(obj). You might need some compatibility code for "Zope 3" libraries, to introduce aq_base calls in the right places. On any one object, you use either parent pointers to real persistent objects, or you use Acquisition. Zope 2.12 has not introduced anything to actually store pointers to real objects. It just provides forward compatibility, so objects that do have those pointers, can avoid using Acquisition. And all of that while keeping the Acquisition API's like "from Acquisition import aq_parent, aq_get") intact and working for both types of approaches. Or well, this is a bit of a lie, Zope 2.12 actually did change things for browser views, so those don't inherit from Acquisition anymore, but with those view.__parent__ is just the same as view.context - so it's easier. We worked on actually storing parent pointers on objects during last years Zope 4 sprint at Plone Conf. But today I doubt using parent pointers actually works. Or at least you have to be really careful with Acquisition wrappers and cannot use API's like OFS.CopySupport or ZEXP export. Hanno _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )