On Mon, Apr 23, 2012 at 6:26 PM, Tim Delaney <timothy.c.dela...@gmail.com> wrote: > And doing that would make zero sense, because it directly contradicts the > whole *point* of "is". The point of "is" is to tell you whether or not two > references are to the same object. This is a *useful* property.
It's useful for mutable objects, yes. How is it useful for immmutable things? They behave identically everywhere where you don't directly ask the question of "a is b" or "id(a) == id(b)". And whenever you ask that question, the answer is an implementation detail: sometimes equality implies "is", sometimes not, it depends on the values and the implementation of Python, because the implementation is free to intern liberally. Therefore it shouldn't make any difference if we make equality _always_ imply "is", since that was always on the table as an implementation detail. I think the real breakage is that now "a is b" is not equivalent to "id(a) == id(b)" (unless you try to hack that as well.) > I'll leave aside the question of how you determine if an object is > immutable, and restrict the discussion to a few built-in types that are > known to be immutable. Right. This is what everyone does, when they implement this "modified is" (e.g. ECMAScript Harmony's "is" operator works this way: http://wiki.ecmascript.org/doku.php?id=harmony:egal ). > If two objects are not the same object, then lying and saying they are would > remove the opportunity for various programming techniques, such as > interning. Of course, you could say that all immutable objects should be > interned automatically. There are a couple problems with this that I can > think of off the top of my head. Hold up, why do we give up interning? As you mention later, interning only involves hashing and equality comparisons, not id() or is. (e.g. we can intern `y` just fine with `y = cache.setdefault(y, y)`) -- Devin -- http://mail.python.org/mailman/listinfo/python-list
