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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -