Re: Another of those is issues.

2009-03-24 Thread J. Cliff Dyer
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

Re: Another of those is issues.

2009-03-22 Thread Emanuele D'Arrigo
Thank you all for the replies! Manu -- http://mail.python.org/mailman/listinfo/python-list

Re: Another of those is issues.

2009-03-21 Thread Bruno Desthuilliers
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

Re: Another of those is issues.

2009-03-21 Thread Martin v. Löwis
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

Another of those is issues.

2009-03-20 Thread Emanuele D'Arrigo
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,

Re: Another of those is issues.

2009-03-20 Thread Benjamin Peterson
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

Re: Another of those is issues.

2009-03-20 Thread Scott David Daniels
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

Re: Another of those is issues.

2009-03-20 Thread Tim Wintle
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

Re: Another of those is issues.

2009-03-20 Thread Steve Holden
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 =

Re: Another of those is issues.

2009-03-20 Thread Terry Reedy
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

Re: Another of those is issues.

2009-03-20 Thread Christian Heimes
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