[Python-ideas] Module name [was Re: Pre-PEP: adding a statistics module to Python]

[Mark Dickinson]

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.

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.

Any of math.statistics, math.stats, statistics or stats works for me.  My
(weak) preference would be for a 'statistics' top-level module.

Mark


On Tue, Aug 6, 2013 at 6:42 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 6 August 2013 15:31, Joshua Landau <joshua at landau.ws> wrote:
> > On 6 August 2013 06:22, Michele Lacchia <michelelacchia at gmail.com>
> wrote:
> >>
> >> Il giorno 06/ago/2013 02:12, "Alexander Belopolsky" <
> alexander.belopolsky at gmail.com> ha scritto:
> >>>
> >>> On Mon, Aug 5, 2013 at 8:01 PM, MRAB <python at mrabarnett.plus.com>
> wrote:
> >>>>
> >>>> Well, "statistics" is no longer than "subprocess" anyway.
> >>>
> >>> Right, but subprocess was never intended for use in the "calculator
> mode."
> >>
> >> 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.
> >
> > To be fair that's a false analogy as math is module for mathematical
> > functions (of which statistics is a subset) and fractions contains
> > numeric types.
> >
> > Additionally, whether things are inside other modules hasn't been very
> > constant over time -- there are several cases where modules were
> > combined and spliced although mostly in the Python 2 to 3 border.
>
> The main reason we've switched to nesting things inside other
> namespaces is when a name is somewhat ambiguous on its own, or risks a
> name clash with a PyPI project.
>
> concurrent.futures is so named to help avoid confusion with the
> finance industry notion of "futures"
> unittest.mock avoids colliding with the PyPI original
>
> In this case, since Steven's module doesn't handle complex numbers (as
> I understand it), putting it inside the "math" namespace helps make
> that clear. If it does handle complex numbers where appropriate, then
> the top level name would make more sense.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130806/c8b4c267/attachment.html>