Identity of bound methods

[AbeLeite]

BPO	36175
Nosy	@methane

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2019-03-04.03:22:43.589>
created_at = <Date 2019-03-04.02:42:19.522>
labels = ['interpreter-core', '3.8', 'type-bug', '3.7', 'invalid']
title = 'Identity of bound methods'
updated_at = <Date 2019-03-04.06:01:56.118>
user = 'https://bugs.python.org/AbeLeite'

bugs.python.org fields:

activity = <Date 2019-03-04.06:01:56.118>
actor = 'Abe Leite'
assignee = 'none'
closed = True
closed_date = <Date 2019-03-04.03:22:43.589>
closer = 'methane'
components = ['Interpreter Core']
creation = <Date 2019-03-04.02:42:19.522>
creator = 'Abe Leite'
dependencies = []
files = []
hgrepos = []
issue_num = 36175
keywords = []
message_count = 5.0
messages = ['337063', '337066', '337067', '337070', '337071']
nosy_count = 2.0
nosy_names = ['methane', 'Abe Leite']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue36175'
versions = ['Python 2.7', 'Python 3.6', 'Python 3.7', 'Python 3.8']

[AbeLeite]

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

[methane]

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.)

[AbeLeite]

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

[methane]

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.

[AbeLeite]

Thank you for the explanation. I looked up the documentation for descriptors and I understand better now. I appreciate it!

-Abe