On Mon, Dec 30, 2019, 5:17 PM Andrew Barnert > The fact that all three of the alternate orders anyone’s asked for or > suggested turned out to be spurious, and nobody can think of a good use for > a different one, that’s a pretty good argument that YAGNI. >
I think everyone agrees that the only actual use cases are 'ignore', 'poison', 'raise', and I suppose 'fast/unsafe'. I missed some details in trying to emulate IEEE total_order(), but my point was never that it was desirable, just easy (but it turns out to be slightly less way than I first thought). Any actual order involving NaNs is a fool's mission. Wait, what’s wrong with the behavior of math.isnan for floats? If you want > a NaN test that differs from the one defined by IEEE, I think we’re off > into uncharted waters. > I do not believe or accept that statistics is meant to "blow up on non-floats". I might like math.isnan() to behave better with non-floats numbers, but that's a different issue. You seem to propose a perfectly good version of a general is_nan() later in your comment. Wait, are you arguing that we should just offer a generic is_nan function > (as a builtin?), instead of adding an on_nan handler parameter to median > and friends? > I don't think a built-in. Maybe in math, or statistics. I don't care if it's spelled '_isnan()' for private use by statistics. I'm not worried about public functionality. Just avoiding repetition in different paths in 'median_<whatever>' and xtile().
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/COXBHXBXE6GPA53VDGX6NOSSPKSVCA22/ Code of Conduct: http://python.org/psf/codeofconduct/
