(Note: I have no dog in this fight, I would be happy with a changed
"is" or with the current one -- leaky abstractions are fine with
me, provided I am told *when* they may -- or sometimes may not --
leak.
)
a = (1, 2, [3, 4, 5])
b = (1, 2, [3, 4, 5])
a == b True
a is b # Using the proposed definition
True
I believe that John Nagle's proposal would make "a is b" false,
because while a and b are both immutable, they contain *different*
refernces to *mutable* objects (thus failing the "identical
references to immutable objects" part of the claim).
On the other hand, should one do:
L = [3, 4, 5]
a = (1, 2, L)
b = (1, 2, L)
then "a is b" should (I say) be True under the proposal -- even
though they contain (identical) references to *mutable* objects.
Loosely speaking, we would define the "is" relation as:
(x is y) if and only if
(id(x) == id(y)
or
(x is immutable and y is immutable and
(for all components xi and yi of x, xi is yi)))
In this case, even if the tuples "a" and "b" have different id()s,
we would find that both have an immutable type, and both have
components -- in this case, numbered, subscriptable tuple elements,
but instances of immutable class types like decimal.Decimal would
have dictionaries instead -- and thus we would recursively apply
the modified "is" definition to each element. (For tuples, the
"all components" implies that the lengths must be equal; for class
instances, it implies that they need to have "is"-equal attributes,
etc.)
It's not entirely clear to me whether different immutable classes
(i.e., different types) but with identical everything-else should
compare equal under this modified "is". I.e., today:
$ cp /usr/lib/python2.?/decimal.py /tmp/deccopy.py
$ python
...False
and obviously "x is y" is currently False:
<class 'deccopy.Decimal'>
However, even though the types differ, both x and y are immutable
[%] and obviously (because I copied the code) they have all the
same operations. Since they were both created with the same starting
value, x and y will behave identically given identical treatment.
As such, it might be reasonable to ask that "x is y" be True
rather than False.
[% This is not at all obvious -- I have written an immutable class,
and it is pretty easy to accidentally mutate an instance inside
the class implementation. There is nothing to prevent this in
CPython, at least. If there were a minor bug in the decimal.Decimal
code such that x.invoke_bug() modified x, then x would *not* be
immutable, even though it is "intended to be". (As far as I know
there are no such bugs in decimal.Decimal, it's just that I had
them in my "Money" class.)]
