Why keep identity-based equality comparison?
steven.bethard at gmail.com
Wed Jan 11 13:55:55 EST 2006
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
> 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
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
More information about the Python-list