Hi Steve, Since you found the external methods arguments thing interesting, here's another challenge for you... ;-) (it's actually from the same nav_tree method) I was trying to use 'if o in REQUEST.PARENTS' to expand branches on the way to the currently displayed object and was running into trouble which lead me to try out the following code: `REQUEST.PARENTS[0]`+`o`+`o==REQUEST.PARENTS[0]`+`o is REQUEST.PARENTS[0]` Now, this renders the following in the case where the branch _should_ expand: <Folder instance at 88cbb30><Folder instance at 88cbb30>00 What I don't understand is how two objects, apparently at the same memory location, return false from both 'object1==object2' and 'object1 is object2'. Again, any ideas? cheers, Chris The only vaguely related thing I can think of is that this is happening 'cos I'm working in a version and the folder object has been changed and REQUEST.PARENTS contains the unchanged version while o contains the changed version. If this is causing it, it's a bug ;-)
Chris Withers wrote:
I was trying to use 'if o in REQUEST.PARENTS' to expand branches on the way to the currently displayed object and was running into trouble which lead me to try out the following code:
`REQUEST.PARENTS[0]`+`o`+`o==REQUEST.PARENTS[0]`+`o is REQUEST.PARENTS[0]`
Now, this renders the following in the case where the branch _should_ expand: <Folder instance at 88cbb30><Folder instance at 88cbb30>00
What I don't understand is how two objects, apparently at the same memory location, return false from both 'object1==object2' and 'object1 is object2'.
Smells like an Acquisition Wrapper misunderstanding :-) http://www.zope.org/Members/michel/Projects/Interfaces/AcquisitionWrappedObj... Use the aq_self or aq_parent attribute to do your comparisons to get your object out of its magic acquisition wrapper. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
Steve Alexander wrote:
Smells like an Acquisition Wrapper misunderstanding :-)
You should change your name to Jim... ...or have you been bitten by this before? Do you know if objects in PARENTS are acquisition wrapped? cheers and much we're-not-worthy'ing, Chris
Chris Withers wrote:
...or have you been bitten by this before?
Nope -- I just like reading impenetrable documentation :-)
Do you know if objects in PARENTS are acquisition wrapped?
I'm pretty sure that they are. Anyway, I was wrong in my last email -- you should be comparing using the aq_base attribute, not the aq_self attribute, as the aq_self attribute could itself be wrapped. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
Steve Alexander wrote:
Do you know if objects in PARENTS are acquisition wrapped?
I'm pretty sure that they are.
They are indeed, in fact, pretty much everything is :( The only way to check if o is in PARENTS appears to be: if o.aq_base in map (lambda o : o.aq_base,PARENTS): ..nice... :/ Two questions: 1. Is there a better way of doing the above? 2. Is there any case where a Zope object isn't going to have a .aq_base attribute? cheers, Chris
Chris Withers wrote:
Steve Alexander wrote:
Do you know if objects in PARENTS are acquisition wrapped? I'm pretty sure that they are.
They are indeed, in fact, pretty much everything is :( The only way to check if o is in PARENTS appears to be:
if o.aq_base in map (lambda o : o.aq_base,PARENTS):
Hmm, is there anyway the Acquisition ExtensionClass(right thing? I'm not too hot here ;-) could be altered such that, if r1 and r2 are two different acquisition wrappers for the same object that: r1 == r2 and r1 in [r2,x,y] would return true? It might be best to leave (r1 is r2) returning false as it does now so that you can actually tell if things aren't what you expected ;-) Any ideas? cheers, Chris PS: This question is still worrying me :(
2. Is there any case where a Zope object isn't going to have a .aq_base attribute?
Chris Withers wrote:
Chris Withers wrote:
Steve Alexander wrote:
Do you know if objects in PARENTS are acquisition wrapped? I'm pretty sure that they are.
They are indeed, in fact, pretty much everything is :( The only way to check if o is in PARENTS appears to be:
if o.aq_base in map (lambda o : o.aq_base,PARENTS):
Hmm, is there anyway the Acquisition ExtensionClass(right thing? I'm not too hot here ;-) could be altered such that, if r1 and r2 are two different acquisition wrappers for the same object that:
r1 == r2 and r1 in [r2,x,y]
would return true?
Yes. I think that this would be a great idea. Note that if r1 implements __cmp__, then it is called. This means that you could implement the proposed behavior now with: def __cmp__(self, o): return cmp( id(getattr(self, 'aq_base', self)), id(getattr(o, 'aq_base', self)) ) It also means that (with the proposed change) that '==' will only be equivalent to an identity comparison if an object doesn't define comparison. In most cases, however, this shouldn't be a problem.
It might be best to leave (r1 is r2) returning false as it does now so that you can actually tell if things aren't what you expected ;-)
Good, because there's no hook to override 'is'.
PS: This question is still worrying me :(
2. Is there any case where a Zope object isn't going to have a .aq_base attribute?
Sure. There is no guarentee that all objects are wrapped. A common idiot for dealing with this is getattr(o, 'aq_base', o). So your example above would become: if getattr(o, 'aq_base', o) in map ( lambda o : getattr(o, 'aq_base', o), PARENTS) I've considered implementing the aquisition attributes in the Implicit and and explict base classes, which would probably be a good idea. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Chris Withers wrote:
Two questions:
1. Is there a better way of doing the above?
Does the method aq_inContextOf() do what you want? http://www.zope.org/Members/michel/Projects/Interfaces/AcquisitionWrappedObj... ---- aq_inContextOf(other [, inner]) Check whether the object is in the context of another object, other, meaning that the other object is in the acquisition hierarchy abovethe object. An optional argument, inner, can be provided to indicate wither the innermost wrapped object should be checked. ----
2. Is there any case where a Zope object isn't going to have a .aq_base attribute?
I don't think there is any such case generally, as all Zope objects support acquisition, and therefore inherit from Acquisition.Implicit or Acquisition.Explicit. However, someone could write a Product with a class that doesn't support Acquisition. I think I'd consider that a bug in their Product, though. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
Steve Alexander wrote:
Does the method aq_inContextOf() do what you want?
Not really, sicne it's not linked to the URL traversal, which PARENTS is. Or am I getting that wrong? ;-)
However, someone could write a Product with a class that doesn't support Acquisition. I think I'd consider that a bug in their Product, though.
Me too... Thanks for all you help, Chris
participants (3)
-
Chris Withers -
Jim Fulton -
Steve Alexander