[Python-Dev] Re: redefining is (original) (raw)
Josiah Carlson jcarlson at uci.edu
Fri Mar 19 18:41:00 EST 2004
- Previous message: [Python-Dev] Re: redefining is
- Next message: [Python-Dev] redefining is
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> Equivalency at this point in time is different from being equivalent at > all points in time in the future.
If you like.
I guess it is all how we interpret the word "equivalent", but then again, that is what the remainder of the message was about. Differentiating between being equivalent now, and always being equivalent, and how we can (relatively) easily implement 'always equivalent'.
> Equivalent now, is something we can test easily with the current '=='.
Not really, at least not in the presence of user-define ==.
I should have said that I was only really referring to built-in types. I mistakenly believed my later comment regarding mutable and immutable user defined classes being impossible to deal with clarified this. I'll be more explicit next time.
[snip]
> 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... Certainly not complete, as it doen't include long or bool.
Taking your changes into account, and fixing a case when two mutable objects are passed, but are the same object (also removing the requirement for a sane id())...
#list possibly not complete. _immutables = (int, str, float, tuple, long, bool, complex, 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 a is b 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 if len(a) != len(b): return False for x,y in zip(a,b): if not interchangeable(a,b): return False return True #are immutable but aren't a container return a == b
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
This extends the interchangeable sufficiently such that you test equality (==) for those things that are not containers, test identity for those that are mutable, and only do full interchangeable tests for those that are tuples.
Also, this code does not take ImmutableSet into account. ... Correct. As things stand today, two distinct objects of user-defined classes should never be considered interchangeable.
Technically, ImmutableSet is a user-defined class. Considering that we can setstate on it, further makes it /far from/ immutable, and shouldn't even be handled by interchangeable, though the new version tests for identity using 'is' for mutable objects, which I believe is sufficient.
- Josiah
- Previous message: [Python-Dev] Re: redefining is
- Next message: [Python-Dev] redefining is
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]