Max M wrote at 2006-11-29 12:53 +0100:

Dieter Maurer skrev:

...

Yuri wrote at 2006-11-28 14:23 +0100:

...

here: http://docs.neuroinf.de/programming-plone/ate we can read:

obj = brain.getObject().aq_base

why .aq_base and not only brain.getObject()? :)

Usually, it is a bad idea to use "aq_base" in Zope applications

You should carefully examine the context of the code fragment above. Maybe, the context is one of the rare situations where "aq_base" is called for...

Why is it rare?

I often need to check if an object has a certain attribute. Getting aquisition into the mix is a bad idea there.::

name = getattr(obj, 'name')

Is a lot different than

name = getattr(obj.aq_base, 'name')

In the first example you don't know if the name attribute is an aquired object or an attribute on the actual object. Which can make for uncontrollable results.

You may use it often -- but you may then work suboptimally :-) You are right that "getattr(obj, 'name')" and "getattr(obj.aq_base, 'name')" are quite different -- in that the first acquires "name" if "obj" does not have such an attribute. On the other hand "getattr(obj.aq_base, 'name')" is adequate only for simple result object types -- those that do not support acquisition. If the result supports acquisition, then the result is only partially acquisition wrapped. Partially acquisition wrapped objects tend to produce interesting surprises: they get e.g. 'getPhysicalPath' and 'absolute_url' wrong and cannot access 'REQUEST'. For your use case above, I have therefore proposed an "hasattr_unacquired" standard function ages ago (the Zope tracker will show you when exactly). Here, the name explicitly spells out what the function is used for -- such that even a newbie can understand what is happening (which might not be the case with an "obj.aq_base" use). Such an "hasattr_unacquired" drastically reduces the need to use "aq_base" (or the even more horrible "aq_inner.aq_explicit" variant for untrusted code). -- Dieter