This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients belopolsky, docs@python, ncoghlan, rhettinger, v+python
Date 2011-04-28.07:55:04
SpamBayes Score 6.959344e-11
Marked as misclassified No
Message-id <BANLkTikf18q7_zEdeVxx9i4bnD7ohqPyAA@mail.gmail.com>
In-reply-to <1303975610.29.0.536082648672.issue11945@psf.upfronthosting.co.za>
Content
On Thu, Apr 28, 2011 at 3:26 AM, Nick Coghlan <report@bugs.python.org> wrote:
..
> 1. Write fully conformant implementations of IEEE754 floating point types, including the non-reflexive NaN comparisons
> (keeping in mind that, as a value-based specification, "same payload" is the closest IEEE754 can get to "same object")
>

If being "fully conformant" with various IEEE standards was a design
goal for Python, we would have leap seconds in the datetime module.
:-)

Python builtin float equality being reflexive does not in any way
inhibits anyone's ability to *write* a fully conforming
implementation.  In fact, if we ever get arithmetic operations
implemented for ctypes types, I would argue that c_double comparison
of c_double values would need to be changed to match C behavior.  (I
am +0 on changing that even without implementing arithmetics.)

I realize, however that by "status quo" you mean container operations
not calling __eq__ on identical objects.  I agree that this should not
change.  Making float comparison reflexive will actually make this
feature less controversial.
History
Date User Action Args
2011-04-28 07:55:05belopolskysetrecipients: + belopolsky, rhettinger, ncoghlan, v+python, docs@python
2011-04-28 07:55:05belopolskylinkissue11945 messages
2011-04-28 07:55:04belopolskycreate