why () is () and [] is [] work in other way?

[Devin Jeanpierre]

On Mon, Apr 23, 2012 at 6:26 PM, Tim Delaney
<timothy.c.delaney at 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