<div dir="ltr">The complex numbers argument seems like a red herring to me:  I can't imagine why we'd ever want a cmath.statistics module.  I can't see any problem with having future functions in math.statistics that can either take float inputs and return a float result, or take complex inputs and return a complex result.<div>
<br></div><div>One of the biggest reasons that it's useful to have both math.sqrt and cmath.sqrt is that the latter returns complex numbers for negative *float* inputs, and that's going to be undesirable for many (but desirable for some).  I can't think of any kind of statistics that would need that kind of separation.<div>
<br></div><div>Any of math.statistics, math.stats, statistics or stats works for me.  My (weak) preference would be for a 'statistics' top-level module.</div><div><br></div><div>Mark</div></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Aug 6, 2013 at 6:42 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 6 August 2013 15:31, Joshua Landau <<a href="mailto:joshua@landau.ws">joshua@landau.ws</a>> wrote:<br>
> On 6 August 2013 06:22, Michele Lacchia <<a href="mailto:michelelacchia@gmail.com">michelelacchia@gmail.com</a>> wrote:<br>
>><br>
>> Il giorno 06/ago/2013 02:12, "Alexander Belopolsky" <<a href="mailto:alexander.belopolsky@gmail.com">alexander.belopolsky@gmail.com</a>> ha scritto:<br>
>>><br>
>>> On Mon, Aug 5, 2013 at 8:01 PM, MRAB <<a href="mailto:python@mrabarnett.plus.com">python@mrabarnett.plus.com</a>> wrote:<br>
>>>><br>
>>>> Well, "statistics" is no longer than "subprocess" anyway.<br>
>>><br>
>>> Right, but subprocess was never intended for use in the "calculator mode."<br>
>><br>
>> What about the fraction module? It could be in math but it isn't. It could also be frac or fracs, but it is not. For consistency the module name IMHO should be statistics.<br>
><br>
> To be fair that's a false analogy as math is module for mathematical<br>
> functions (of which statistics is a subset) and fractions contains<br>
> numeric types.<br>
><br>
> Additionally, whether things are inside other modules hasn't been very<br>
> constant over time -- there are several cases where modules were<br>
> combined and spliced although mostly in the Python 2 to 3 border.<br>
<br>
</div>The main reason we've switched to nesting things inside other<br>
namespaces is when a name is somewhat ambiguous on its own, or risks a<br>
name clash with a PyPI project.<br>
<br>
concurrent.futures is so named to help avoid confusion with the<br>
finance industry notion of "futures"<br>
unittest.mock avoids colliding with the PyPI original<br>
<br>
In this case, since Steven's module doesn't handle complex numbers (as<br>
I understand it), putting it inside the "math" namespace helps make<br>
that clear. If it does handle complex numbers where appropriate, then<br>
the top level name would make more sense.<br>
<br>
Cheers,<br>
Nick.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
</div></div></blockquote></div><br></div>