> Equivalency at this point in time is different from being equivalent at > all points in time in the future. If you like. > Equivalent now, is something we can test easily with the current '=='. Not really, at least not in the presence of user-define ==. > 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). No, you're right. > 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)) Certainly not complete, as it doen't include long or bool. > 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 That's not quite what I had in mind: You're testing for element identity rather than interchangeability. Perhaps something more like this: if len(a) != len(b): return False for x, y in zip(a, b): if !interchangeable(x, y): return False return True > #are immutable but aren't a container > return a == b Also, this code does not take ImmutableSet into account. > 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. Correct. As things stand today, two distinct objects of user-defined classes should never be considered interchangeable.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4