On Thu, Apr 28, 2011 at 4:04 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On Fri, Apr 29, 2011 at 8:55 AM, Guido van Rossum <gu...@python.org> wrote: >> Sorry, we'll have to make an exception for those of course. This will >> somewhat complicate the interpretation of well-behaved, because those >> are *not* well-behaved as far as containers go (both dict key lookup >> and list membership are affected) but it is not a bug -- however it is >> a bug to put these in containers and then use container comparisons on >> the container. > > That's a point in favour of the status quo, though - with the burden > of enforcing reflexivity placed on the containers, types are free to > make use of rich comparisons to return more than just simple > True/False results.
Possibly. Though for types that *do* return True/False, NaN's behavior can still be infuriating. > I hadn't really thought about it that way before this discussion - it > is the identity checking behaviour of the builtin containers that lets > us sensibly handle cases like sets of NumPy arrays. But do they? For non-empty arrays, __eq__ will always return something that is considered true, so any hash collisions will cause false positives. And look at this simple example: >>> class C(list): ... def __eq__(self, other): ... if isinstance(other, C): ... return [x == y for x, y in zip(self, other)] ... >>> a = C([1,2,3]) >>> b = C([2,1,3]) >>> a == b [False, False, True] >>> x = [a, a] >>> b in x True -- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
