On Fri, May 27, 2005 at 09:25:58AM -0400, Jim Fulton wrote:
> Tim Peters wrote:
> >OTOH, defining & importing a utility function-- say, safehasattr()
> >--would make it all explicit. That's what ZODB does.
(BTW, I just went grepping for this safehasattr() in zope 2.7.6's
ZODB and didn't find anything. What's it called?)
There are ~700 calls to hasattr() currently in the Zope core (ouch!).
Are there cases where the current use of hasattr() is considered safe?
Or since it's "broken by design", should we replace all 700
calls with this hypothetical safe_hasattr()?
While we're on the subject, the other day Dieter Maurer was complaining that:
An incredibly long time ago, I filed a feature request for
"hasattr_unacquired" -- together with patch, unit tests and
update. I am convinced that such a function in the
DTML namespace (and therefore always available in restricted code)
would be much clearer than the "aq_inner.aq_explicit" dance.
But, unfortunately, the Zope developers decided not to
accept my patch or the "hasattr_unacquired" idea
and instead made "aq_inner" accessible by untrusted code.
A bad decision!
As a consequence, you see the nasty code.
So, assuming we add a safe_hasattr() function, maybe it could take
an extra keyword arg?
def safe_hasattr(obj, attr, acquired=True, _marker=):
if not acquired:
obj = aq_inner(aq_explicit(obj))
return getattr(obj, attr, _marker) is not _marker
> > I certainly
> >agree that changing the behavior of a builtin function by magic is at
> >best highly dubious practice.
> In fact, consider this vetoed for the Zope core. :)
Fine, that nicely reduces the scope of the discussion :-)
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -