<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Jan 7, 2019 at 8:39 AM Steven D'Aprano <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Its not a bug in median(), because median requires the data implement a <br>
total order. Although that isn't explicitly documented, it is common <br>
sense: if the data cannot be sorted into smallest-to-largest order, how <br>
can you decide which value is in the middle?<br>
<br>
What is explicitly documented is that median requires numeric data, and <br>
NANs aren't numbers. So the only bug here is the caller's failure to <br>
filter out NANs. If you pass it garbage data, you get garbage results.<br>
<br>
Nevertheless, it is a perfectly reasonable thing to want to use data <br>
which may or may not contain NANs, and I want to enhance the statistics <br>
module to make it easier for the caller to handle NANs in whichever way <br>
they see fit. This is a new feature, not a bug fix.<br></blockquote><div><br></div><div>So then you are arguing that making reasonable treatment of NANs the default is not breaking backwards compatibility (because previously the data was considered wrong). This sounds like a good idea to me. Presumably the NANs are inserted into the data explicitly in order to signal missing data -- this seems more plausible to me (given the typical use case for the statistics module) than that they would be the result of a computation like Inf/Inf. (While propagating NANs makes sense for the fundamental arithmetical and mathematical functions, given that we have chosen not to raise an error when encountering them, I think other stdlib libraries are not beholden to that behavior.)<br></div><div> </div></div>-- <br><div dir="ltr" class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div></div>