[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