On Wed, Mar 24, 2010 at 11:55 AM, Alexander Belopolsky <alexander.belopol...@gmail.com> wrote: > On Wed, Mar 24, 2010 at 2:36 PM, Guido van Rossum <gu...@python.org> wrote: > .. >> Probably because we were blindly following the IEEE standard without >> understanding it in every detail. > > Are you talking about "accidental" support for NaNs in older versions > of Python or about recent efforts to support them properly in math and > decimal modules?
My recollection include recent efforts, such as the math.isnan() function. I don't recall ever hearing an argument for the peculiar behavior of NaN in comparisons beyond "this is what the IEEE standard prescribes." > I feel you are too harsh on the developers that worked in this area. Maybe. I didn't mean to put down individuals complicit in the decision -- in fact I would say that I am to blame myself for not probing deeper. > I dare to suggest that the current situation is not due to lack of > understanding of the standard, but due to pragmatic decisions made in > early development and desire for backward compatibility in the recent > versions. I think that originally NaN (and Inf) behavior was so platform-dependent that it really wouldn't have mattered if we had changed it. > Is this an area where design changes are feasible? IIRC, NaN support > was never "officially" in the language, but it may have changed with > the decimal module. It has been at least since 2.6 introduced math.isnan(), and ISTR there was a proposal to add a separate module to deal with NaN and Inf properly in a pure-python library module. -- --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
