Namespaces, ZPublisher, DocumentTemplate question
Hi! I've got a product that inherits from Folder, and creates some magic "content" by overriding __bobo_traverse__. Now I've got the problem that I cannot access the "magic" items from within a DocumentTemplate like in <dtml-var special>. The interesting thing is, that I've overloaded __getattr__ and __getitem__, and it seems both are never called. (Actual code snippets at the end) So I'm wondering how DocumentTemplates (and say Page Templates) access the items and properties? Andreas code snippet: def __getattr__(self,k,*args): r=Folder.Folder.__getattr__(self,k,*args) print "__getattr__(%r,%r)==%r" % (self,key,r) return r def has_key(self,key): r=Folder.Folder.has_key(self,key) print "%r.has_key(%r)==%r" % (self,key,r) return r def __getitem__(self,key): print "__getitem__(%r,%r)" % (self,key) try: return Folder.Folder.__getitem__(self,key) except KeyError: try: return self.__bobo_traverse__(self,None,key) except AttributeError: raise KeyError,key
Andreas Kostyrka writes:
I've got a product that inherits from Folder, and creates some magic "content" by overriding __bobo_traverse__.
Now I've got the problem that I cannot access the "magic" items from within a DocumentTemplate like in <dtml-var special>.
The interesting thing is, that I've overloaded __getattr__ and __getitem__, and it seems both are never called. (Actual code snippets at the end)
So I'm wondering how DocumentTemplates (and say Page Templates) access the items and properties?
Andreas
code snippet: def __getattr__(self,k,*args): r=Folder.Folder.__getattr__(self,k,*args) print "__getattr__(%r,%r)==%r" % (self,key,r) This will not work as you expect!
"__getattr__" is only called, when the normal lookup does not succeed. "Folder.__getattr__" is inherited from "Persistent" and will serve only very few attributes. For all others, you will get an "AttributeError", before you print anything. Furthermore, "__getattr__" takes only one (non-self) arguement. Your code above (with this strange "*args" code) will pass two. You will get a "TypeError" before you print anything.
def has_key(self,key): r=Folder.Folder.has_key(self,key)
"Folder" implements the mapping interface only very partially. It does not implement "has_key".
... def __getitem__(self,key): print "__getitem__(%r,%r)" % (self,key) try: return Folder.Folder.__getitem__(self,key) except KeyError: try: return self.__bobo_traverse__(self,None,key) except AttributeError: raise KeyError,key "__getitem__" is only called, when you explicitely use "instance[key]".
Dieter
Hi! I've just discovered, that Acquisition does not work with __getattr__, right? (I assume that this is so because something like getattr(mybase,attr) is called during the acquisition process to prevent infinite recursion.) Anyway to get around that? (To basically get a wrapped self from somewhere?) I see two "solutions": -) I let some method (like pretraversal) acquire my object and store a reference in my object. This might work if the object is changed seldom and the method is called regularly enough, ... -) I walk the frame stack and extract the wrapped self from it. Not really nice, but then Zope does a number of black magic things :) Andreas
From: "Andreas Kostyrka" <andreas@kostyrka.priv.at>
I've just discovered, that Acquisition does not work with __getattr__, right?
That depends on what you mean with "does not work". :-)
(I assume that this is so because something like getattr(mybase,attr) is called during the acquisition process to prevent infinite recursion.)
Anyway to get around that? (To basically get a wrapped self from somewhere?)
That's what self usually is... :-) I think you need to answer a couple of questions: 1. What is it you want to do? 2. How are you trying to do it? 3. What is happening when you try to do it? It's hard to give solutions when you don't know the problem. :-) Best Regards Lennart Regebro http://www.easypublisher.com/
Am Mon, 2002-09-23 um 00.18 schrieb Lennart Regebro:
From: "Andreas Kostyrka" <andreas@kostyrka.priv.at>
I've just discovered, that Acquisition does not work with __getattr__, right?
That depends on what you mean with "does not work". :-)
(I assume that this is so because something like getattr(mybase,attr) is called during the acquisition process to prevent infinite recursion.)
Anyway to get around that? (To basically get a wrapped self from somewhere?)
That's what self usually is... :-) Nope it is not. In a normal method you can access something acquired like this: self.acquired_value. Even more, this works for __bobo_traverse__. It just works for the publishing not accessing my attributes later on during publication.
The problem is, that __getattr__ does not have access to the acquisition chain. Now I storing the "acquisition chain" in the object is not a sound proposition, because it is not thread safe. Worse the object might be accessed in some way that makes the acquisition chain not be updated.
I think you need to answer a couple of questions: 1. What is it you want to do? 2. How are you trying to do it? 3. What is happening when you try to do it?
It's actually trivial ;) I want to acquire some things in __getattr__. Basically I want to insert an additional access step like this: 1.) a.b.c.o -> o if o exists in c 2.) a.b.c.o -> Folder.o (where Folder is acquired from a.b.c) if it's exist. 3.) a.b.c.o -> tries to acquire o from a.b.c. Basically I want "Transparent Folders" which get their "transparent values from the Acquisition path. Well, I just had an idea for an implementation: Third idea: I return some callable object the was generated specifically for the access from the __getattr__. This is than executed with Acquisition enabled, so it can try to get the real one, .... Problem: What if the attribute does not exist? I do not thing that Zope reacts to well when instead of a AttributeError exception it gets some object that raises AttributeError when accessed, .... Andreas
From: "Andreas Kostyrka" <andreas@kostyrka.priv.at>
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.
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 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) self._v_ignore_attrib=[] # Return it in context of self, forgetting # its location and acting as if it were located # in self. return aq_base(subob) else: self._v_ignore_attrib.append(name) 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.
Well, I just had an idea for an implementation: Third idea: I return some callable object the was generated specifically for the access from the __getattr__. This is than executed with Acquisition enabled, so it can try to get the real one, .... Problem: What if the attribute does not exist? I do not thing that Zope reacts to well when instead of a AttributeError exception it gets some object that raises AttributeError when accessed, ....
Andreas
Am Mon, 2002-09-23 um 10.35 schrieb Lennart Regebro:
From: "Andreas Kostyrka" <andreas@kostyrka.priv.at>
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 getattr(aq_base(self),name) 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? self._v_ignore_attrib=[] # Return it in context of self, forgetting # its location and acting as if it were located # in self. return aq_base(subob) else: self._v_ignore_attrib.append(name)
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 Wrapper. 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 Zope. 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 this style!" 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 :( Andreas
From: "Andreas Kostyrka" <andreas@kostyrka.priv.at>
Well, where do you intenden your getattr to get the attribute from?
As I said, this is an example. This getattr part is supposed to be replaced with whatever you do to get the attribute. Otehrwise it would be rather useless, since it wouldn't do anything that isn't already done. :-)
Difficult. Because __getattr__ does not have access to the acquisition chain.
Well, you fix that with __of__, which is what I was going to say, but forgot. :-) I won't venture in giving you any example code, though, but the PortalSkins is one place to look. Also, depending of when you want the properties from the transparent folder to be aqcuirable you might be able to wrap the object by calling __of__ instead of overriding it. Best Regards Lennart Regebro, Torped http://www.easypublisher.com/
Andreas Kostyrka <andreas@kostyrka.priv.at> wrote:
Am Mon, 2002-09-23 um 00.18 schrieb Lennart Regebro:
From: "Andreas Kostyrka" <andreas@kostyrka.priv.at>
I've just discovered, that Acquisition does not work with __getattr__, right?
That depends on what you mean with "does not work". :-)
(I assume that this is so because something like getattr(mybase,attr) is called during the acquisition process to prevent infinite recursion.)
Anyway to get around that? (To basically get a wrapped self from somewhere?)
That's what self usually is... :-) Nope it is not. In a normal method you can access something acquired like this: self.acquired_value. Even more, this works for __bobo_traverse__. It just works for the publishing not accessing my attributes later on during publication.
The problem is, that __getattr__ does not have access to the acquisition chain. Now I storing the "acquisition chain" in the object is not a sound proposition, because it is not thread safe. Worse the object might be accessed in some way that makes the acquisition chain not be updated.
Anoter way to do that is to play games with __of__. Look at the implementation of the skins tool in CMF for an example. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
Am Mon, 2002-09-23 um 11.12 schrieb Florent Guillaume:
Anoter way to do that is to play games with __of__. Look at the implementation of the skins tool in CMF for an example. Doesn't help, as I do NOT know my container :(
Basically __getattr__ when called does not know it's containment anymore. :( Andreas
Andreas Kostyrka <andreas@kostyrka.priv.at> wrote:
Am Mon, 2002-09-23 um 11.12 schrieb Florent Guillaume:
Anoter way to do that is to play games with __of__. Look at the implementation of the skins tool in CMF for an example. Doesn't help, as I do NOT know my container :(
Yes it does. __of__ is non-intuitive but it can work.
Basically __getattr__ when called does not know it's containment anymore. :(
You didn't look a the code I pointed to you. Look at CMFCore/Skinnable to be precise (not everything is to be used of course). * In __of__ you store the parent in a volatile attribute, * in __getattr__ you lookup the volatile attribute This works as long as your object is not used in several different acquisition contexts. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
At 16:29 2002-09-23 +0000, Florent Guillaume said:
You didn't look a the code I pointed to you. Look at CMFCore/Skinnable to be precise (not everything is to be used of course).
* In __of__ you store the parent in a volatile attribute, * in __getattr__ you lookup the volatile attribute
This works as long as your object is not used in several different acquisition contexts.
Hi Florent, Would you care to elaborate on that last sentence? :-) Could you give an example when it wouldn't work? Best Regards, Johan Carlsson -- Torped Strategi och Kommunikation AB Johan Carlsson johanc@torped.se Mail: Birkagatan 9 SE-113 36 Stockholm Sweden Visit: Västmannagatan 67, Stockholm, Sweden Phone +46-(0)8-32 31 23 Fax +46-(0)8-32 31 83 Mobil +46-(0)70-558 25 24 http://www.torped.se http://www.easypublisher.com
On Mon, 2002-09-23 at 19:04, Johan Carlsson [Torped] wrote:
At 16:29 2002-09-23 +0000, Florent Guillaume said:
You didn't look a the code I pointed to you. Look at CMFCore/Skinnable to be precise (not everything is to be used of course).
* In __of__ you store the parent in a volatile attribute, * in __getattr__ you lookup the volatile attribute
This works as long as your object is not used in several different acquisition contexts.
Hi Florent, Would you care to elaborate on that last sentence? :-) Could you give an example when it wouldn't work?
Sure. If your object with special __of__ and __getattr__ is o and you do x = f.o # o.__of__(f) is called so f is stored in o._v_stuff y = f.g.o # o.__of__(f.g) is called so f.g is stored in o._v_stuff x['foo'] # o's __getattr__ finds f.g stored in _v_stuff and not f. But it's not necessarily a problem if you take care to use aq_inner. That depends on the use you have for the parent, really. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
Am Mon, 2002-09-23 um 19.28 schrieb Florent Guillaume:
But it's not necessarily a problem if you take care to use aq_inner. That depends on the use you have for the parent, really. General Zope site? Basically I want this capability to be incorporated in some general building class, ... So I cannot know what my users (that might be website developers) will be doing with the gadget, right? Actually I could be in the unhappy situation to be forced to share parts of websites I currently develop with newly developed ones, ...
But __of__ is still a really nice trick :) Andreas
Am Mon, 2002-09-23 um 18.29 schrieb Florent Guillaume:
Andreas Kostyrka <andreas@kostyrka.priv.at> wrote:
Am Mon, 2002-09-23 um 11.12 schrieb Florent Guillaume:
Anoter way to do that is to play games with __of__. Look at the implementation of the skins tool in CMF for an example. Doesn't help, as I do NOT know my container :(
Yes it does. __of__ is non-intuitive but it can work. So how do I call it? return myitem.__of__(self) Doesn't make sense, as self is not wrapped and as such DOES not contain any knowledge how it was accessed, ... /site1/shared/a/b/c/x /site2/shared/a/b/c/x might be quite different things?
My problem especially is not generating a wrapper, but to acquire some object from up my acquisition chain, ...
Basically __getattr__ when called does not know it's containment anymore. :(
You didn't look a the code I pointed to you. Look at CMFCore/Skinnable to be precise (not everything is to be used of course).
* In __of__ you store the parent in a volatile attribute, * in __getattr__ you lookup the volatile attribute
This works as long as your object is not used in several different acquisition contexts.
But exactly THIS I want to support. How should I know if the object will not be used sometime in the future with different contexts. How can I know that my content objects will not be recycled in a second Virtual Host? etc. Andreas
Andreas Kostyrka writes:
...
__of__ is non-intuitive but it can work. So how do I call it? return myitem.__of__(self) Doesn't make sense, as self is not wrapped and as such DOES not contain any knowledge how it was accessed, ... Acquisition lookup is implemented by a recursive function:
While you are right that "self" does not know how it was accessed, the recursive lookup function does (on its runtime stack). And it will provide the missing context when it builds further wrappers on returning from the recursive calls. Dieter
Am Die, 2002-09-24 um 21.32 schrieb Dieter Maurer:
Andreas Kostyrka writes:
...
__of__ is non-intuitive but it can work. So how do I call it? return myitem.__of__(self) Doesn't make sense, as self is not wrapped and as such DOES not contain any knowledge how it was accessed, ... Acquisition lookup is implemented by a recursive function:
While you are right that "self" does not know how it was accessed, the recursive lookup function does (on its runtime stack). And how do I return an attribute that is acquired (but not down th main acquisition path, but on a side line?) I assume that I could probably play some silly games with __of__ to make my additional Acquisition objects to come just before my object in the acquisition path, ... But still it seems to me, it could be nice if __getattr__ would be called on an explicit wrapper of self, instead of the direct pure self.
Andreas -- Andreas Kostyrka <andreas@kostyrka.priv.at>
From: "Andreas Kostyrka" <andreas@kostyrka.priv.at>
And how do I return an attribute that is acquired (but not down th main acquisition path, but on a side line?)
You shouldn't, really.
I assume that I could probably play some silly games with __of__ to make my additional Acquisition objects to come just before my object in the acquisition path, ...
Yup, much better idea.
Am Mit, 2002-09-25 um 10.06 schrieb Lennart Regebro:
From: "Andreas Kostyrka" <andreas@kostyrka.priv.at>
And how do I return an attribute that is acquired (but not down th main acquisition path, but on a side line?)
You shouldn't, really. Why not?
I assume that I could probably play some silly games with __of__ to make my additional Acquisition objects to come just before my object in the acquisition path, ...
Yup, much better idea. Done. Only thing I've noticed that the Catalog shows this "additional" path elements, ... See also www.zope.org/Members/yacc/FlexData ;), I've left the old __getattr__ hack commented in the source, ...
Andreas -- Andreas Kostyrka <andreas@kostyrka.priv.at>
From: "Andreas Kostyrka" <andreas@kostyrka.priv.at> To: "Lennart Regebro" <lennart@torped.se>
You shouldn't, really.
Why not?
Because that's not how it's supposed to work. You can override __getattr__ to have special magick attributes. Acquisition is not a special magick attribute. __getattr__ is only called when an attribute aren't found in a "normal" way, and in the context of Zope, Acquicistion would be regarded as normal. :-)
Done. Only thing I've noticed that the Catalog shows this "additional" path elements, ...
I guess that depends on when you patch in the extra object in the acquisition. If you do it in __of__() then I guess it's visible all the time. This may or may not be a good idea. :)
Am Mit, 2002-09-25 um 12.44 schrieb Lennart Regebro:
From: "Andreas Kostyrka" <andreas@kostyrka.priv.at> To: "Lennart Regebro" <lennart@torped.se>
You shouldn't, really.
Why not?
Because that's not how it's supposed to work. You can override __getattr__ to have special magick attributes. Acquisition is not a special magick attribute. __getattr__ is only called when an attribute aren't found in a "normal" way, and in the context of Zope, Acquicistion would be regarded as normal. :-) But my attributes are not normal. So I should generate them by __getattr__. Only by noticing that I could get the same effect by putting my attribute source in front of my object in the acquisition chain.
The question is still, how does one a __getattr__ that needs (as a client) acquisition to calculate the attribute. (Basically __of__ works only if I do not need to know the attribute name and do not mind a changed acquisition chain, __getattr__ works only if I do not need Acquisition, ...)
Done. Only thing I've noticed that the Catalog shows this "additional" path elements, ...
I guess that depends on when you patch in the extra object in the acquisition. If you do it in __of__() then I guess it's visible all the Well, where else can I patch it in?
Andreas -- Andreas Kostyrka <andreas@kostyrka.priv.at>
From: "Andreas Kostyrka" <andreas@kostyrka.priv.at>
But my attributes are not normal. So I should generate them by __getattr__. Only by noticing that I could get the same effect by putting my attribute source in front of my object in the acquisition chain.
The question is still, how does one a __getattr__ that needs (as a client) acquisition to calculate the attribute.
You don't. __getattr__ is used if you for example want data from a subobject to behave like it's attributes directly on the object. Trying to get data from another object in the ZODB to behave like they are attributes directly on the object with __gettattr__ is problematic, because that is not what it's designed for, and because in __getattr__ you don't have a context. Making data from another object in the ZODB to behave like they are attributes directly on the object is however exactly what Acquisition is designed for, and hence it's easier to do it that way.
(Basically __of__ works only if I do not need to know the attribute name
??? Why wouldn't it work if you know the attribute name? What it doesn't do is to only work with some attributes, it works with all attributes, maybe that is what you mean? This usually don't give you any negative side effects.
I guess that depends on when you patch in the extra object in the acquisition. If you do it in __of__() then I guess it's visible all the
Well, where else can I patch it in?
Overriding __of__ means that you are changing how the acquisition chain looks and behaves for the object. But you can also just wrap the object by calling __of__ whenever you need it wrapped instead of overriding it. If I remember the syntax correctly "foo = self.__of__(magickfolder)" would wrap self in magickfolder, and make it acquire magickfolders attributes, so that after doing this "foo.bla" would get the attribute from magickfolder if it doens't exist on self. This you can do just before you need that behaviour, and it will be a completely local behaviour. Don't spank me if I don't remember all the details here, I haven't looked at the code where we do this in a couple of months. :-) We insert our templates in the acquisition chain when index_html is called, so that the correct template is used when rendering. This insertion then only affects the rendering. From: "Dieter Maurer" <dieter@handshake.de>
"__getattr__" is used before acquisition comes into play.
You are probably correct. Nevertheless, you can't push acquired object into the acqusition context in __getattr__, because the object inside __getattr__ has no context, and hence no objects are acquired. But of course it makes sense that __getattr__ is called before the acquisition comes into play, because otherwise you wouldn't be able to override acquired attributes. :-)
Lennart Regebro writes:
... Because that's not how it's supposed to work. You can override __getattr__ to have special magick attributes. Acquisition is not a special magick attribute. __getattr__ is only called when an attribute aren't found in a "normal" way, and in the context of Zope, Acquicistion would be regarded as normal. :-) I had written the exact same statement some time ago. Nevertheless, it is wrong :( Now, I know it better:
"__getattr__" is used before acquisition comes into play. Dieter
On Monday, September 23, 2002, at 09:14 AM, Andreas Kostyrka wrote:
Am Mon, 2002-09-23 um 11.12 schrieb Florent Guillaume:
Anoter way to do that is to play games with __of__. Look at the implementation of the skins tool in CMF for an example. Doesn't help, as I do NOT know my container :(
Basically __getattr__ when called does not know it's containment anymore. :(
This is why my stock suggestion to needing to do anything with acquisition and __getattr__ (or any other acquisition jump-arounds) is: Don't. There are a lot of complexities that can arise out of Acquisition, Wrappers, and so on, that really require a deep understanding of exactly HOW acquisition works, versus what it usually does. The other problem with __getattr__ is interfacing with Persistence. ZODB handles it now, but it wasn't all that long ago that it couldn't. But with Acquisition - once you go beyond "fair use", there's not enough Scotch in the world to kill the brain cramp. :)
Jeffrey P Shell writes:
... The other problem with __getattr__ is interfacing with Persistence. ZODB handles it now, but it wasn't all that long ago that it couldn't. But, it is unlikely that it will loose this capability again...
Dieter
Andreas Kostyrka wrote:
The problem is, that __getattr__ does not have access to the acquisition chain.
I think it does, but I may be corrected. Some things to check for: 1. Do the classes of you object (and containing objects) inherit for Acquisition.Implicit? 2. Are you getting hold of the object in such a way that it is acquisition wrapped? cheers, Chris
Am Mon, 2002-09-23 um 13.10 schrieb Chris Withers:
Andreas Kostyrka wrote:
The problem is, that __getattr__ does not have access to the acquisition chain.
I think it does, but I may be corrected. Well, it's definitly not wrapped. I know because I had to work around that. And it's definitly quite sick how I do this :)
Some things to check for:
1. Do the classes of you object (and containing objects) inherit for Acquisition.Implicit?
I inherit from OFS.Folder.Folder, this should be enough, wouldn't it? Especially Acquisition works quite well in all other methods, just not __getattr__.
2. Are you getting hold of the object in such a way that it is acquisition wrapped?
Well, I'm not getting hold of anything. It's more like Zope is getting hold of my objects to publish. As I've solved my problem (well, it works, I understand the problem, and I know the correct solution, but I shying away of hacking Acquisition. It's easier (for me) to get my wrapper from the Python frame stack than to patch Acquisition.c.) Andreas
Andreas Kostyrka writes:
I've just discovered, that Acquisition does not work with __getattr__, right? It does, just not the way, you expect it:
The actual attribute lookup (for attributes not starting with "aq_") is always made with an unwrapped object. That's the reason why the "self" in "getattr" is unwrapped. Special operations ensure for Python Methods (the one of "ExtensionClass" not Zope's!) that their "self" receives part of the acquisition context (it's rarely the full context, just enough to work in most cases). They are rebuild with the current node as "self", when the recursive lookup comes back out of "aq_self" iff the method's "self" is "aq_self". You may have a look at my "Reference" product <http://www.dieter.handshake.de/pyprojects/zope> There, I fight with the peculiarities of "__getattr__" and acquisition context for methods. Dieter
On Sun, 2002-09-22 at 18:39, Andreas Kostyrka wrote:
Hi!
I've just discovered, that Acquisition does not work with __getattr__, right?
(I assume that this is so because something like getattr(mybase,attr) is called during the acquisition process to prevent infinite recursion.)
I believe that is correct.
Anyway to get around that? (To basically get a wrapped self from somewhere?)
You might want to look at PortableHole for inspiration. It does get around getattr problems with acquisition: http://www.zope.org/Members/TheJester/PortableHole Cheers, Leo -- Ideas don't stay in some minds very long because they don't like solitary confinement.
participants (8)
-
Andreas Kostyrka -
Chris Withers -
Dieter Maurer -
Florent Guillaume -
Jeffrey P Shell -
Johan Carlsson [Torped] -
Lennart Regebro -
Leonardo Rochael Almeida