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:
>
> >>
Thank you all for the replies!
Manu
--
http://mail.python.org/mailman/listinfo/python-list
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
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 = aFunc
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 MyClass.my
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 = aFunctio
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
>
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 myMethod(s
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
Emanuele D'Arrigo 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
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
T
11 matches
Mail list logo
