[Python-Dev] Re: redefining is

[Josiah Carlson]

> I haven't distinguished between equivalent and interchangeable.  I think
> that most people would consider "equivalent" and "interchangeable" to mean
> the same thing.

No.

Equivalency at this point in time is different from being equivalent at
all points in time in the future.

Equivalent now, is something we can test easily with the current '=='.

Equivalent at all times in the future (what I would consider
interchangeable) requires minimally testing object identities.  This
seems to be going a bit beyond what 'is' is doing right now, as shown
by:

>>> a = []
>>> b = []
>>> x1 = (a,b)
>>> y1 = (a,b)
>>> x1 is y1
False

'is' seems to be doing a shallow check of object identity (I may be
wrong).

Testing whether or not two objects will be identical in the future would
likely require a single-level id check along with being able to test
whether an object is mutable or not.  For built-in structures (lists,
tuples, dictionaries, strings...), this isn't so bad, we know what is
immutable or not.  Seemingly a reasonable algorithm for determining
whether two objects are interchangeable is as follows...

#list possibly not complete.
_immutables = (int, str, float, tuple, type(None))
immutables = dict([i, None for i in _immutables])
def interchangeable(a,b):
    if type(a) not in immutables or type(b) not in immutables:
        return False
    if type(a) is type(b) and type(a) is tuple:
        #are immutable, but may contain objects whose
        #identity may be important for the future
        ia = map(id, a)
        ib = map(id, b)
        return ia == ib
    #are immutable but aren't a container
    return a == b


For user-defined classes, unless an interface is designed so that
classes can say, "I am mutable" or "I am immutable", and there are ways
to get their 'contents' (if such a thing makes sense), then testing
potential interchangeability is a moot point, and is (currently)
impossible.

 - Josiah