The following code produces unexpected behavior in all versions of Python I have tested. >>> class a: ... def method(self): pass >>> inst = a() >>> inst.method is inst.method False It appears that id(inst.method) changes each time inst.method is accessed by normal means. So the tuple (id(inst.method), id(inst.method)) will have the same item repeated, but the tuple (id(inst.method), inst.method, id(inst.method)) will not. Note that for unbound methods and other functions, this issue does not occur. This creates a transparency issue for bound instance methods taking the place of functions. My apologies if this is a design decision that has already been resolved! It just seemed like a strange behavior to me. --Abe
It is a designed behavior. I agree that it looks strange to some users who don't know implementation. And that's why people should not use `is` normally, except some use cases (e.g. `is None`.)
Hi Inada-san, Could you explain (or send me a link to) what happens when an instance method is accessed and why this should be different from what happens when an unbound method is accessed? The `is` keyword has been very useful for me in introspection cases and that is why I'm confused that it doesn't behave as expected here. Thank you, Abe
> > Could you explain (or send me a link to) what happens when an instance method is accessed descriptor of function object creates bound method. You can google "descriptor python". > and why this should be different from what happens when an unbound method is accessed? No "should", just "can". `3 + 5 is 8` can be True of False by language definition, while `3 + 5 == 8` is always True. Like it, descriptor may or may not same instance by language definition. > > The `is` keyword has been very useful for me in introspection cases and that is why I'm confused that it doesn't behave as expected here. > You're confused because you're using wrong guide; `is`. There are many cases that language spec doesn't define same instance is returned or not.
