types.UnboundMethodType is types.MethodType

[Carlos Ribeiro]

Just curious. I was trying to test for a class method in some code of
mine, and stumbled on a few things that I really could not understand:

# C is a class, m is a class methodTrue
# C is a class, cm is a class method(504034256, 504034256)

I don't get it. Why to have two different identifiers that are in fact the same?

BTW - That's my Python version:'2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit (Intel)]'
--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)

 

[Michele Simionato]

Just curious. I was trying to test for a class method in some code of
mine, and stumbled on a few things that I really could not understand:

# C is a class, m is a class method
True
# C is a class, cm is a class method
(504034256, 504034256)

I don't get it. Why to have two different identifiers that are in fact the same?

Backward compatibility?

Here is from the source of types.py:

<...>

class _C:
def _m(self): pass
ClassType = type(_C)
UnboundMethodType = type(_C._m) # Same as MethodType
_x = _C()
InstanceType = type(_x)
MethodType = type(_x._m)

<....>


Michele Simionato

 

[Carlos Ribeiro]

Backward compatibility?

Here is from the source of types.py:

<...>

class _C:
def _m(self): pass
ClassType = type(_C)
UnboundMethodType = type(_C._m) # Same as MethodType
_x = _C()
InstanceType = type(_x)
MethodType = type(_x._m)

<....>

It's probably a good explanation, if we remember that Python went
through lots of changes since 1.5.2 days wrt to the typing system
*and* to the method dispatch system. But I don't think it's right,
because as it is now I can't reliably trust the results of:

isinstance(method, UnboundMethodType)

It's possible that today's implementation uses the same type, and what
changes is only the fact that a unbounded method hasn't still filled
some attributes. In this case, there is no sense to talk about a
UnboundMethodType. But *if* the types are different, then it should
reflect on the type tests, don't you think?

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)