On Fri, 2009-03-20 at 11:20 -0700, Emanuele D'Arrigo wrote:
Hi everybody,
I was unit testing some code today and I eventually stumbled on one of
those is issues quickly solved replacing the is with ==. Still,
I don't quite see the sense of why these two cases are different:
def
Thank you all for the replies!
Manu
--
http://mail.python.org/mailman/listinfo/python-list
Emanuele D'Arrigo a écrit :
Hi everybody,
I was unit testing some code today and I eventually stumbled on one of
those is issues quickly solved replacing the is with ==. Still,
I don't quite see the sense of why these two cases are different:
def aFunction():
... pass
...
f = aFunction
m is c.myMethod
False --- What? Why is that?
I think nobody has said this plainly yet (although Terry
points it out also): You cannot rely that
foo.bar is foo.bar
for any object foo and any attribute bar. In some cases,
that relation may hold, in other cases, it may not.
It depends on
Hi everybody,
I was unit testing some code today and I eventually stumbled on one of
those is issues quickly solved replacing the is with ==. Still,
I don't quite see the sense of why these two cases are different:
def aFunction():
... pass
...
f = aFunction
f is aFunction
True --- Ok,
Emanuele D'Arrigo manu3d at gmail.com writes:
class MyClass(object):
... def myMethod(self):
... pass
...
c = MyClass()
m = c.myMethod
m is c.myMethod
False --- What? Why is that?
Can anybody shed some light? Or point to a resource to look at? Or
what's the bit of
Emanuele D'Arrigo wrote:
Hi everybody, ...
f = aFunction
f is aFunction
True --- Ok, this seems reasonable. Nevertheless, I suspect I
shouldn't quite rely on it.
Actually, that's fine, you are simply comparing a pair of references
class MyClass(object):
... def
On Fri, 2009-03-20 at 11:20 -0700, Emanuele D'Arrigo wrote:
def aFunction():
... pass
...
f = aFunction
f is aFunction
True --- Ok, this seems reasonable. Nevertheless, I suspect I
shouldn't quite rely on it.
You can rely on this in the above - you've just assigned the name f to
Emanuele D'Arrigo wrote:
Hi everybody,
I was unit testing some code today and I eventually stumbled on one of
those is issues quickly solved replacing the is with ==. Still,
I don't quite see the sense of why these two cases are different:
def aFunction():
... pass
...
f =
Emanuele D'Arrigo wrote:
Hi everybody,
I was unit testing some code today and I eventually stumbled on one of
those is issues quickly solved replacing the is with ==. Still,
I don't quite see the sense of why these two cases are different:
def aFunction():
... pass
...
f = aFunction
f
Terry Reedy wrote:
Compare that to MyClass.myMethod is MyClass.myMethod, which is True at
least in 3.0.
It's true because Python 3.0 has no unbound methods. MyClass.myMethod
returns the function object. It's possible to get the same behavior in 2.x:
MyClass.myMethod.im_func is
11 matches
Mail list logo