Why keep identity-based equality comparison?

Mike Meyer mwm at mired.org
Wed Jan 11 01:27:24 CET 2006


spam.noam at gmail.com writes:
> It seems to me that both Mike's and Fuzzyman's objections were that
> sometimes you want the current behaviour, of saying that two objects
> are equal if they are: 1. the same object or 2. have the same value
> (when it's meaningful).  In both cases this can be accomplished pretty
> easily: You can do it with a try..except block, and you can write the
> try...except block inside the __contains__ method.  (It's really pretty
> simple: try:     return a == b except TypeError:     return a is b )

This isn't "easy". It's an ugly hack you have to use everytime you
want to iterate through a heterogenous set doing equality tests.

You're replacing "false" with an "emphathetic false", that *all*
containers to change for the worse to deal with it.

> Also, Mike said that you'll need an idlist object too - and I think
> he's right and that there's nothing wrong with it.

Except that we now need four versions of internal data structures,
instead of two: list, tuple, idlist, idtuple; set, idset, frozenset,
frozenidset, and so on. What's wrong with this is that it's ugly.

> Note that while you
> can easily define the current == behaviour using the proposed
> behaviour, you can't define the proposed behaviour using the current
> behaviour.

Yes you can, and it's even easy. All you have to do is use custom
classes that raise an exception if they don't

> Also note that using the current behaviour, you can't easily
> treat objects that do define a meaningful value comparison, by
> identity.

Yes you can. Just use the "is" operator.

Note that this behavior also has the *highly* pecular behavior that a
doesn't necessarily equal a by default.

I will point out why your example usages aren't really usefull if
you'll repeat your post with newlines.

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



More information about the Python-list mailing list