[Python-Dev] redefining is
Samuele Pedroni
pedronis at bluewin.ch
Fri Mar 19 17:07:30 EST 2004
At 15:33 19.03.2004 -0500, Andrew Koenig wrote:
> > Okay, but I don't see why that implementation detail is important.
>
>It is important because it causes programs to behave differently on
>different implementations.
>
> > > So what I'm claiming is that there should be a way of asking: Given two
> > > objects, is there any way to distinguish them aside from their identity?
>
> > Why do you need to ask that question? Further more, why is it
> > important enough to require a builtin operator?
>
>It certainly doesn't *require* a builtin operator. I do think, however,
>that the proposed comparison is more useful than "is" in most contexts in
>which programmers use "is" today. In particular, programs that use "is" can
>easily contain bugs that testing on a particular implementation can never
>reveal, and using the proposed comparison instead makes such bugs much less
>likely (and perhaps even impossible).
maybe, OTOH I suspect that people most puzzled by
>>> a = 1
>>> b = 1
>>> a is b
True
>>> a = 99
>>> b = 99
>>> a is b
True
>>> a = 101
>>> b = 101
>>> a is b
False
really simply expect there to be just one 1 and 99 and 101, not an
half-a-page definition of 'is' or some such involving the notion of
(im)mutability.
More information about the Python-Dev
mailing list