descriptor dilemma

[john]

Hello,

I was wondering if someone could explain the following situation to me
please:
def f(self):
pass

c = C()
c.f

C.__dict__['f'].__get__(c,C)

c.f == C.__dict__['f'].__get__(c,C) True
c.f is C.__dict__['f'].__get__(c,C)

False

Why do c.f and C.__dict__['f'].__get__(c,C) compare as equal under ==
but not under *is* ?

Thanks,

John

 

[=?iso-8859-1?q?S=E9bastien_Boisg=E9rault?=]

Yup ?!? Weird ... especially as:

id(c.f) == id(C.__dict__['f'].__get__(c,C))

True

I was pretty sure that 'id(a) == id(b)' iff 'a is b' ...

I thought initially that you had two *copies* of the
same method bot obviously it's not true ...

SB

 

[Jeff Epler]

Yup ?!? Weird ... especially as:

id(c.f) == id(C.__dict__['f'].__get__(c,C))

True

Here, c.f is discarded by the time the right-hand-side of == is
executed. So the object whose id() is being calculated on the
right-hand-side could turn out to be the same, since the two objects
have disjoint lifetimes.

Here are some more cases of the same thing:

id([]) == id([]) 1
id([]) == id([1])

1

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFCePZ0Jd01MZaTXX0RAorrAJ40RCbKQudlFZ66TuRRix/Uv10e/gCghqVd
pRQFX+sxAR09/uyuKn2mkRI=
=BTaK
-----END PGP SIGNATURE-----

 

[Peter Otten]

Why do c.f and C.__dict__['f'].__get__(c,C) compare as equal under ==
but not under *is* ?

These variations are equivalent. Every attribute access gives you a new
bound method:
.... def f(self): pass
....True

'a is b' is true only when the names a and b are bound to the same object.
For bound methods, c.f is c.f == True would mean that Python would have to
cache them, and I don't see a potential advantage of that.
'a == b' on the other hand does what the programmer specifies:
.... def __eq__(self, other): return True
....True

It makes sense for bound methods to compare equal if they refer to the same
function and instance (though I don't know if the class is checked, too).

Peter

 

[=?iso-8859-1?q?S=E9bastien_Boisg=E9rault?=]

id(c.f) == id(C.__dict__['f'].__get__(c,C))

True

Here, c.f is discarded by the time the right-hand-side of == is
executed. So the object whose id() is being calculated on the
right-hand-side could turn out to be the same, since the two objects
have disjoint lifetimes.

Understood. I guess I was influenced by C++ where a temporary survives
up to the end of the complete statement in which it was created. Right
?

SB