> > 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