On 4/27/2011 8:43 PM, Nick Coghlan wrote:
On Thu, Apr 28, 2011 at 12:42 PM, Stephen J. Turnbull
<step...@xemacs.org> wrote:
Mark Dickinson writes:
> Declaring that 'nan == nan' should be True seems attractive in
> theory,
No, it's intuitively attractive, but that's because humans like nice
continuous behavior. In *theory*, it's true that some singularities
are removable, and the NaN that occurs when evaluating at that point
is actually definable in a broader context, but the point of NaN is
that some singularities are *not* removable. This is somewhat
Pythonic: "In the presence of ambiguity, refuse to guess."
Refusing to guess in this case would be to treat all NaNs as
signalling NaNs, and that wouldn't be good, either :)
I like Terry's suggestion for a glossary entry, and have created an
updated proposal at http://bugs.python.org/issue11945
(I also noted that array.array is like collections.Sequence in failing
to enforce the container invariants in the presence of NaN values)
In that bug, Nick, you mention that reflexive equality is something that
container classes rely on in their implementation. Such reliance seems
to me to be a bug, or an inappropriate optimization, rather than a
necessity. I realize that classes that do not define equality use
identity as their default equality operator, and that is acceptable for
items that do not or cannot have any better equality operator. It does
lead to the situation where two objects that are bit-for-bit clones get
separate entries in a set... exactly the same as how NaNs of different
identity work... the situation with a NaN of the same identity not being
added to the set multiple times seems to simply be a bug because of
conflating identity and equality, and should not be relied on in
container implementations.
_______________________________________________
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
