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. /Slightly/ less hackish: Replace hasattr() in the __builtin__ module with your own implementation that treats instances of FuncDesigner specially. Least ugly suggestion: Just don't use hasattr(); use your `x in dir(y)` trick instead. > Subject: [...] I think this is Python bug Nope, that's just how hasattr() works. See http://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.) """ 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). Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
