Mark Dickinson <[EMAIL PROTECTED]> added the comment:
This is indeed interesting. For what it's worth, I think
the Python 3.0 behaviour is the right one, here. Perhaps
it's worth adding a test to Python 3.0 to make sure that
this behaviour doesn't accidentally disappear, or at least
to make sure that someone thinks about it before making
the behaviour disappear.
But in general I don't think the fact that NaNs are weird
should get in the way of optimizations. In other words,
I'm not sure that Python should be asked to guarantee
anything more than "b == b" returning False when b is
a NaN. It wouldn't seem unreasonable to consider
behaviour of nans in containers (sets, lists, dicts)
as undefined when it comes to equality and identity
checks.
There are other questionable things going on when NaNs
are put into containers. For example:
>>> a = float('nan')
>>> b = [a]
>>> a in b
True
A strict reading of the definition of 'in' would say
that "a in b" should return False here, since a is not
equal to any element of b. But I presume that the 'in'
operator does identity checks under the hood before
testing for equality. 'Fixing' this so that nans did
the right thing might slow down a lot of other code
just to handle one peculiar special case correctly.
Michael, is this adversely affecting real-world code?
If not, I'd be inclined to say that it's not worth
changing Python's behaviour here.
_______________________________________
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4296>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
