types.UnboundMethodType is types.MethodType

Discussion in 'Python' started by Carlos Ribeiro, Oct 7, 2004.

  1. 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
    >>> c.m

    <bound method C.m of <__main__.C instance at 0x0120E350>>
    >>> isinstance(c.m, types.UnboundMethodType)

    True
    # C is a class, cm is a class method
    >>> C.cm

    <bound method classobj.cm of <class __main__.C at 0x0120D870>>
    >>> isinstance(C.cx, types.UnboundMethodType)

    True
    >>> types.UnboundMethodType is types.MethodType

    True
    >>> types.UnboundMethodType, types.MethodType

    (<type 'instancemethod'>, <type 'instancemethod'>)
    >>> id(types.UnboundMethodType), id(types.MethodType)

    (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:
    >>> sys.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:
    mail:
    Carlos Ribeiro, Oct 7, 2004
    #1
    1. Advertising

  2. Carlos Ribeiro <> wrote in message news:<>...
    > 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
    > >>> c.m

    > <bound method C.m of <__main__.C instance at 0x0120E350>>
    > >>> isinstance(c.m, types.UnboundMethodType)

    > True
    > # C is a class, cm is a class method
    > >>> C.cm

    > <bound method classobj.cm of <class __main__.C at 0x0120D870>>
    > >>> isinstance(C.cx, types.UnboundMethodType)

    > True
    > >>> types.UnboundMethodType is types.MethodType

    > True
    > >>> types.UnboundMethodType, types.MethodType

    > (<type 'instancemethod'>, <type 'instancemethod'>)
    > >>> id(types.UnboundMethodType), id(types.MethodType)

    > (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
    Michele Simionato, Oct 7, 2004
    #2
    1. Advertising

  3. On 6 Oct 2004 23:49:14 -0700, Michele Simionato
    <> wrote:
    > Carlos Ribeiro <> wrote in message news:<>...
    > > 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
    > > >>> c.m

    > > <bound method C.m of <__main__.C instance at 0x0120E350>>
    > > >>> isinstance(c.m, types.UnboundMethodType)

    > > True
    > > # C is a class, cm is a class method
    > > >>> C.cm

    > > <bound method classobj.cm of <class __main__.C at 0x0120D870>>
    > > >>> isinstance(C.cx, types.UnboundMethodType)

    > > True
    > > >>> types.UnboundMethodType is types.MethodType

    > > True
    > > >>> types.UnboundMethodType, types.MethodType

    > > (<type 'instancemethod'>, <type 'instancemethod'>)
    > > >>> id(types.UnboundMethodType), id(types.MethodType)

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


    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:
    mail:
    Carlos Ribeiro, Oct 7, 2004
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Sathyaish
    Replies:
    2
    Views:
    579
    Sathyaish
    May 22, 2005
  2. Soren Kuula
    Replies:
    2
    Views:
    535
    Henry S. Thompson
    Dec 1, 2005
  3. George Sakkis

    MethodType in python 2.2

    George Sakkis, Nov 10, 2004, in forum: Python
    Replies:
    0
    Views:
    328
    George Sakkis
    Nov 10, 2004
  4. Kirk McDonald

    UnboundMethodType and MethodType

    Kirk McDonald, Feb 8, 2006, in forum: Python
    Replies:
    6
    Views:
    277
    Scott David Daniels
    Feb 9, 2006
  5. Alex Popescu

    MethodType/FunctionType and decorators

    Alex Popescu, Jul 4, 2007, in forum: Python
    Replies:
    12
    Views:
    470
    Alex Popescu
    Jul 6, 2007
Loading...

Share This Page