On Jul 20, 1:37 pm, Chris Rebert <c...@rebertia.com> wrote: > On Tue, Jul 20, 2010 at 3:10 AM, dmitrey <dmitrey.kros...@scipy.org> wrote: > > hi all, > > I have a class (FuncDesigner oofun) that has no attribute "size", but > > it is overloaded in __getattr__, so if someone invokes > > "myObject.size", it is generated (as another oofun) and connected to > > myObject as attribute. > > > So, when I invoke in other code part "hasattr(myObject, 'size')", > > instead o returning True/False it goes to __getattr__ and starts > > constructor for another one oofun, that wasn't intended behaviour. > > Thus "hasattr(myObject, 'size')" always returns True. It prevents me > > of some bonuses and new features to be done in FuncDesigner. > > >>>> 'size' in dir(b) > > False > >>>> hasattr(b,'size') > > True > >>>> 'size' in dir(b) > > True > > > Could you fix it? > > There's probably some hackery you could do to check whether hasattr() > is in the call stack, and then not dynamically create the attribute in > __getattr__ if that's the case, but that's obviously quite kludgey.
It's too unreliable solution, hasattr may or may not appear in stack wrt different cases > /Slightly/ less hackish: Replace hasattr() in the __builtin__ module > with your own implementation that treats instances of FuncDesigner > specially. It's too unreliable as well > Least ugly suggestion: Just don't use hasattr(); use your `x in > dir(y)` trick instead. something in dir() consumes O(n) operations for lookup, while hasattr or getattr() require O(log(n)). It matters for me, because it's inside deeply nested mathematical computations FuncDesigner is made for. > > > Subject: [...] I think this is Python bug > > Nope, that's just how hasattr() works. > Seehttp://docs.python.org/library/functions.html#hasattr(emphasis mine): > """ > hasattr(object, name) > The arguments are an object and a string. The result is True if > the string is the name of one of the object’s attributes, False if > not. (***This is implemented by calling getattr(object, name)*** and > seeing whether it raises an exception or not.) > """ Thus I believe this is very ugly implementation. Some code implemented via "__getattr__" can start to execute arbitrary Python code, that is certainly not desired behaviour "hasattr" was designed for (to perform a check only), and it's too hard to reveal the situations, that makes a potential holes for viruses etc. Moreover, the implementation via "try getattr(object, name)" slowers code evaluation, I wonder why it is implemented so. > > I suppose you could argue for the addition of a __hasattr__ special > method, but this seems like a really rare use case to justify adding > such a method (not to mention the language change moratorium is still > currently in effect). I think much more easier solution would be to implement an additional argument to hasattr, e.g. hasattr(obj, field, onlyLookupInExistingFields = {True/False}). I think by default it's better set to True, now it behaves like False. D. -- http://mail.python.org/mailman/listinfo/python-list
