Am Mon, 2002-09-23 um 10.35 schrieb Lennart Regebro:
> From: "Andreas Kostyrka" <[EMAIL PROTECTED]>
> > Nope it is not. In a normal method you can access something acquired
> > like this:
> > self.acquired_value.
> I often do just that. :-) I'm not 100% sure what you need to include for
> that to work, but I would expect that it is Aqcuisition.Implicit.
Well, Acquisition does not work in __getattr__. This seems trivially
because the "self" is unwrapped in the case of __getattr__, while it's
wrapped when called on a normal method.
> > The problem is, that __getattr__ does not have access to the acquisition
> > chain.
> Well, it does, but it typically causes infinite recursion if you aren't
Well, it would perhaps make sense for Acquisition to use the
equivalent of getattr(self.aq_explicit,name) instead of
This way you have no infinite recursion, but still can acquire things
explicitly with aq_acquire :)
> careful. Something like this might work (this is untested code, adapted from
> something that is a bit more complex that we are doing):
> def __getattr__(self, name, marker=None):
> if not name.startswith('_') and not name.startswith('aq_'):
> if not name in self._v_ignore_attrib:
> subob = getattr(self,name,_marker)
Well, where do you intenden your getattr to get the attribute from?
> # Return it in context of self, forgetting
> # its location and acting as if it were located
> # in self.
> return aq_base(subob)
> raise AttributeError, name
> > Basically I want "Transparent Folders" which get their "transparent
> > values from the Acquisition path.
> Aha. Well, I wouldn't call it trivial, but it is definitely doable.
Difficult. Because __getattr__ does not have access to the acquisition
chain. (Just looking at Acquisition.c makes my head go all jelly ;) )
1.) Change Acquisition to call getattr not on self but on an explicit
wrapper of self. see above.
Problem: Compability with Zope? Should probably work. But perhaps there
are things that rely on self being the object and not an explicit
Problem: The idea of patching Acquisition.c makes my head spin.
Problem: Not possible to fix it up as an Product -> needs a patch to
2.) Fetch my a wrapped copy of self from the Python call stack.
Problem: It's an example of code that would be labelled "Do not copy
Problem: Can break at the most curious moments.
3.) Store the wrapped self in some attribute during traversal.
Problem: This is plain wrong. It's not safe in a number of ways, ...
(threads, multiple acquisition paths, etc.)
I've implemented solution 2) because
- it's packable as a product
- I'm not sure a core change to Acquisition.c is something that has ANY
chance of getting into Zope.
- I'm not 100% sure that changing Acquisition.c will not break Zope in
some subtle ways.
- I'm already past the delivery deadline for my small application of
this. Hacking the Python stack seems something that I can predict much
better than any try to hack Acquisition.c :(
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -