Why keep identity-based equality comparison?

[Steven Bethard]

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.

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

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

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

> 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. ;-)

STeVe