RetroSearch Browse

Fri Mar 19 17:09:50 EST 2004 · http://mail.python.org/pipermail/python-dev/2004-March/043347.html

> >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"
> >caneasily 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.

I think we are agreeing with each other.  Because if "is" were redefined in
the way that was proposed, we would have the following behavior on every
implementation:

	>>> a = 1
	>>> b = 1
	>>> a is b
	True
	>>> a = 99
	>>> b = 99
	>>> a is b
	True
	>>> a = 101
	>>> b = 101
	>>> a is b
	True

regardless of whether id(a)==id(b).

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2004-March/043347.html below:

[Python-Dev] redefining is