On 4/27/2011 11:31 AM, Nick Coghlan wrote:
Currently, Python tries to split the difference: "==" and "!=" follow
IEEE754 for NaN, but most other operations involving builtin types
rely on the assumption that equality is always reflexive (and IEEE754
be damned).
What that means is that "correct" implementations of methods like
__contains__, __eq__, __ne__, index() and count() on containers should
be using "x is y or x == y" to enforce reflexivity, but most such code
does not (e.g. our own collections.abc.Sequence implementation gets
those of these that it implements wrong, and hence Sequence based
containers will handle NaN in a way that differs from the builtin
containers)
And none of that is actually documented anywhere (other than a
behavioural note in the 3.x documentation for
PyObject_RichCompareBool), so it's currently just an implementation
detail of CPython that most of the builtin containers behave that way
in practice.
Which is why I proposed a Glossary entry in another post.
Given the status quo, what would seem to be the path of least resistance is to:
- articulate in the language specification which container special
methods are expected to enforce reflexivity of equality (even for
non-reflexive types)
- articulate in the library specification which ordinary container
methods enforce reflexivity of equality
- fix any standard library containers that don't enforce reflexivity
to do so where appropriate (e.g. collections.abc.Sequence)
+1 to making my proposed text consistenly true if not now ;-).
Backing away from having float and decimal.Decimal respect the IEEE754
notion of NaN inequality at this late stage of the game seems like one
for the "too hard" basket.
Robert Kern confirmed my suspicion about this relative to numpy.
> It also wouldn't achieve much, since we
want the builtin containers to preserve their invariants even for 3rd
party types with a non-reflexive notion of equality.
Good point.
--
Terry Jan Reedy
_______________________________________________
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
