UnboundMethodType and MethodType

[Kirk McDonald]

Hello all,

... def bar(self):
... pass
...

I think is not very consistent
notice q.bar is bounded although type(q.bar)
says it's types.UnboundedMethodType
what do you think?

Regard, Daniel

I think it's perfectly consistent:
.... def bar(self): pass
....-1211888788

It's the same function, whether it's bound or not. Thus, it should
always have the same type. It's simply called in different ways. You can
just as easily say:

As:

-Kirk McDonald

 

[=?ISO-8859-1?Q?Sch=FCle_Daniel?=]

Hello all,
.... def bar(self):
.... pass
....
I think is not very consistent
notice q.bar is bounded although type(q.bar)
says it's types.UnboundedMethodType
what do you think?

Regard, Daniel

 

[Kent Johnson]

I think it's perfectly consistent:

... def bar(self): pass
...
-1211888788

It's the same function, whether it's bound or not. Thus, it should
always have the same type.

No, it's not the same function. You got the same id because you didn't
bind B.bar and b.bar to anything so the id was reused.
... def bar(self): pass
...False

Kent

 

[Scott David Daniels]

Kirk McDonald wrote: ....

No, it's not the same function. You got the same id because you didn't
bind B.bar and b.bar to anything so the id was reused.

... def bar(self): pass
...
False

Kent

To elaborate on this, once 'id' is called, you drop the reference.
This allows quite surprising things like:False

If you wanted to test the original code for identity match:False
is the appropriate test (the 'is' test holds the identities through
the comparison).

By the by, this is tricky stuff, nobody should expect to understand
it thoroughly without both study and testing.

--Scott David Daniels
(e-mail address removed)

 

[=?ISO-8859-1?Q?Sch=FCle_Daniel?=]

[...]

No, it's not the same function. You got the same id because you didn't
bind B.bar and b.bar to anything so the id was reused.

thank you for the explanation
it's indeed tricky with reusing the id
are there some pages on the net to read more about it?
.... def __init__(self,val):
.... self.val = val
.... def bar(self):
.... print self.val
....
the same id-value would enforce two objects to be
of the same type (trivial case)
the reverse is not necessarily true
in this case x.bar and y.bar are of the same type

UnboundMethodType is still not very suitable name for Q().bar
:-/

Regards, Daniel

 

[Kirk McDonald]

To elaborate on this, once 'id' is called, you drop the reference.
This allows quite surprising things like:
False

If you wanted to test the original code for identity match:
False
is the appropriate test (the 'is' test holds the identities through
the comparison).

By the by, this is tricky stuff, nobody should expect to understand
it thoroughly without both study and testing.

--Scott David Daniels
(e-mail address removed)

You know what? That makes perfect sense. Thank you.

-Kirk McDonald

 

[Scott David Daniels]

> Scott David Daniels wrote: <an elaboration on ids and refcounts>
>
> You know what? That makes perfect sense. Thank you.

Thanks a lot for mentioning this. I do try to help out, and sometimes
it feels like talking to the wind. A thanks every now and then is
greatly appreciated.

Just for fun, you can play with:

import sys
sys.getrefcount(123**18)
vs.
sys.getrefcount(12)

You should know that 'small' integers are kept and shared once built.
Similarly, some strings (including all one-character strings and strings
that might be identifiers).
sys.getrefcount('a')
sys.getrefcount('probably_not_really_a_variable')

--Scott David Daniels
(e-mail address removed)