On Tue, Mar 27, 2012 at 3:50 PM, Patrick Gerken <do3cc...@googlemail.com> wrote: > Hmm, since I didn't understand what magic happens with __parent__ pointers, > I tried the following in pdb: > unwrapped = aq_base(a) > unwrapped.__parent__ = aq_base(a.__parent__) > > So I stored a not acquisition wrapped object onto the __parent__ attr > of another unwrapped object. > But then the result, unwrapped.__parent__ was acquisition wrapped again!
Yep. That's one thing we changed in Acquisition and ExtensionClass 4.0a1: Prevent wrappers to be created while accessing __parent__ on types derived from Explicit or Implicit base classes. Usually accessing any attribute on a type derived from Acquisition.Explicit or Implicit will force wrapping to take place, unless there's already a wrapper present. Maybe you remember the whole weird story with browser views in Zope 2 and the need for using "context = aq_inner(self.context)". That was the same problem. Accessing the context attribute of the view (self), created a wrapper equivalent to: "context = context.__of__(self)", as the view itself wasn't wrapped in anything. For views we got rid of the problem by removing the Acquisition.Implicit base class. For normal content classes in Zope 2, removing the Implicit base class is much harder, as there's more stuff depending on it, and you'd need to ensure to switch every type derived from this, to manually store parent pointers. But the 4.0a1 releases of AQ/EC at least treat __parent__ differently, as it doesn't make much sense to force wrapping for that particular attribute. 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 )
