hasattr + __getattr__: I think this is Python bug

[Chris Rebert]

On Tue, Jul 20, 2010 at 3:10 AM, dmitrey <dmitrey.kroshko at 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