Raymond Hettinger added the comment: > Of course the latter isn't guaranteed to help for > non-IEEE-754 platforms -- some platforms don't have > NaNs at all!
ISTM, that years of toying with Infs and Nans has not yielded a portable, workable solution. I'm concerned that further efforts will contort and slow-down our code without benefit. NaNs in particular are a really difficult case because our equality testing routines have a fast path where identity implies equality. I don't think NaNs can be correctly implemented without breaking that fast path which appears throughout the code base (even inside the code for dictobject.c; otherwise, how could you lookup a NaN value). I recommend punting on the subject of NaNs. Attempting to "fix" it will necessarily entail introducing a number of little atrocities that just aren't worth it. IMO, Practicality beats purity on this one. The decimal module provides full support for NaNs. While it is slow, it may be sufficient for someone who isn't happy with the way float handles them. ---------- nosy: +rhettinger __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1580> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
