Why keep identity-based equality comparison?

[Mike Meyer]

Steven Bethard <steven.bethard at gmail.com> writes:
> Mike Meyer wrote:
>> Steven Bethard writes:
>>> Not to advocate one way or the other, but how often do you use
>>> heterogeneous containers?
>> Pretty much everything I do has heterogenous containers of some sort
>> or another.
> Sorry, I should have been a little more specific.  I meant
> heterogeneous containers where you've used the "in" operator.

Fair enough. But the problem occurs with more than just the "in"
operator. Anytime you want to do comparisons on objects in a
heterogenous container, you have to deal with this. This includes
other methods on the container, like list index and remove
moethods. It also means that application-level code that does these
kinds of things have to deal with the possible exceptions as
non-exceptional occurences.

Yeah, there's an easy fix. But it's ugly. 

>> SQL queries made to DP API compliant modules return
>> homogenous lists of heterogenous containers. The cgi module turns the
>> request string into a dictionary-like container of objects with values
>> of different types.
> Are the keys of different types too?  Because if the keys are all the
> same types, then using the "in" operator here wouldn't raise an
> exception.  Unless, of course, you used the "in" operator on the
> .values() of the dictionary...

Nope, not different keys. The canonical example of that would be the
many "memoize" decorators. Note that *inserting* something into such a
dictionary can cause problems, as if two objects hash to the same
value, they get compared for equality.

>> The last thing I did that was both more than a script and didn't use
>> either a database or a web front end was (IIRC) a media player for
>> multiple media types. It revolved around lists of things to play, and
>> the "things" in question could be any "playable" object - video or
>> audio files, track on a CD, or a DVD, or even a playlist.
> That seems pretty reasonable.  Your code used the "in" operator with
> these lists?

I don't really recall - it's been a while. I know I provided searching
facillities, but don't recall if it did a search by doing object
comparisons or not.

>> Come to think of it, recursive data structures of this type - a
>> container that contains a heterogenous list of things, possibly
>> including instances of the container type itself - are pretty
>> common.
> Sure.  I have a number of tree-like containers, and in at least a few
> implementations, BranchNode and LeafNode are different classes.  But I
> haven't needed the "in" operator with these.  With the
> raise-exceptions-between-objects-of-different-types proposal, it would
> probably raise an exception if you tried, but I can't decide whether
> that's a good or a bad thing...

Ugh. That's *ugly*. That means you have to do a complete pass over the
data to figure out if two objects are "different types" or not so you
can decide to raise the exception.

Whether you want to make a seperate "check the type" pass or try doing
equality tests at the same time will depend on the data. If you're
checking a set of 10-million element lists, you *don't* want to check
them all if you can avoid it. Either that, or make the results of the
in operator (and related methods, etc.) depend on the comparison
order. That might be acceptable for lists, but it's really not for
sets or dictionaries.

Actually, that's not sufficient to make the results reliable. If some
objects are allowed to *not* throw exceptions and do
equality-based-on-identity, then the results of a == b won't be the
same as the results of b == a, so looking for a in a container that
has b in it will give different results than looking for b in a
container that has a in it.

>> The other proposal - if I have it right - would not change the
>> behavior of equality comparisons between objects of the same class,
>> but would make comparisons between objects of different classes raise
>> an exception instead of returning false by default.
> Perhaps, given duck-typing, a better proposal would be to raise an
> exception if the objects have different interfaces.  Of course, at the
> moment, I can't think of any even vaguely efficient way of checking
> that. ;-)

Yup. This *really* looks like trying to enforce static typing in a
language that doesn't do anything like it now.

        <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.