[Zope-dev] Re: hasattr implementation for Zope?

Paul Winkler pw_lists at slinkp.com
Fri May 27 11:02:50 EDT 2005


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.  

OK.

(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
documentation       
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?

something like:

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 :-)

-- 

Paul Winkler
http://www.slinkp.com


More information about the Zope-Dev mailing list