Result of ``a is b''

Axel Boldt axelboldt at yahoo.com
Wed Mar 17 08:30:11 EST 2004


"Andrew Koenig" <ark at acm.org> wrote 
> "Axel Boldt" <axelboldt at yahoo.com> wrote

> > Maybe one could redefine "is" on immutables as follows: for strings
> > and numbers it acts as "==", for tuples it acts as componentwise "is".
> > That would be a more useful operator IMHO.
> 
> Can you give a realistic example of code that would benefit from such a
> change?

Well, componentwise "is" on tupels is clearly useful, and not
available with a single operator right now. On the other hand, I don't
think there can be any realistic example where the current version of
"is" on immutables would be useful. Why would anybody ever want to
know whether two strings or tupels are internally stored at the same
location, other than to deduce details of the Python implementation?
In addition, I claim that my redefinition avoids hard to find bugs:
it's entirely possible that some people use "is" on strings, in the
mistaken belief (based on some small examples) that it is faster and
that Python always stores equal strings at the same location [I was
about to do just that, and that's why I started this whole thread].
Their programs may run correctly on some machines and not on others.
Thirdly, my redefinition would reduce the number of unspecified
implementation dependencies of the language. Note that "is" for
mutable objects is an important operator with well-defined semantics
and is not implementation dependent at all, only its behavior for
immutable objects is.

Lastly, using my redefinition of "is", we have the following nice
property for all objects a and b (mutable or immutable):

 a is b  iff  in any code block not containing "id()" or "is", any 
              (or all) occurrances of a can be replaced by b, with
              identical results

In the current implementation, the above equivalence only holds if we
remove "not containing id() or is", and then the statement becomes a
mere tautology without nutritious value.

Axel



More information about the Python-list mailing list