I recently came across the pylint error:
E: 3,4:Foo.foo: An attribute affected in foo line 12 hide this method
in code that boiled down to essentially:
class Foo:
def foo(self):
return True
def foo_override(self):
return False
def __init__(self, override=False):
if override:
self.foo = self.foo_override
Unfortunately that message isn't particularly helpful in figuring out what's going on. I still can't claim to be 100% sure what the message is intended to convey, but I can construct something that maybe it's talking about.
Consider the following using the above class
foo = Foo() moo = Foo(override=True) print "expect True : %s" % foo.foo() print "expect False : %s" % moo.foo() print "expect True : %s" % Foo.foo(foo) print "expect False : %s" % Foo.foo(moo)
which gives output of:
$ python ./foo.py expect True : True expect False : False expect True : True expect False : True
Now, if you read just about any Python tutorial, it will say something along the lines of:
... the special thing about methods is that the object is passed as the first argument of the function. In our example, the call x.f() is exactly equivalent to MyClass.f(x). In general, calling a method with a list of n arguments is equivalent to calling the corresponding function with an argument list that is created by inserting the method’s object before the first argument. [Official Python Tutorial]
The official tutorial above is careful to say in general; others often don't.
The important point to remember is how python internally resolves attribute references as described by the data model. The moo.foo() call is really moo.__dict__["foo"](moo); examining the __dict__ for the moo object we can see that foo has been re-assigned:
>>> print moo.__dict__
{'foo': <bound method Foo.foo_override of <__main__.Foo instance at 0xb72838ac>>}
Our Foo.foo(moo) call is really Foo.__dict__["foo"](moo) -- the fact that we reassigned foo in moo is never noticed. If we were to do something like Foo.foo = Foo.foo_override we would modify the class __dict__, but that doesn't give us the original semantics.
So I postulate that the main point of this warning is to suggest to you that you're creating an instance that now behaves differently to its class. Because the symmetry of calling an instance and calling a class is well understood you might end up getting some strange behaviour, especially if you start with heavy-duty introspection of classes.
Thinking about various hacks and ways to re-write this construct is kind of interesting. I think I might have found a hook for a decent interview question :)