[Python-Dev] Re: redefining is (original) (raw)

Josiah Carlson jcarlson at uci.edu
Fri Mar 19 15:38:45 EST 2004

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.

More information about the Python-Dev mailing list