[Python-ideas] Pre-PEP: adding a statistics module to Python

[Nick Coghlan]

On 3 Aug 2013 12:19, "Andrew Barnert" <abarnert at yahoo.com> wrote:
>
> On Aug 2, 2013, at 16:06, Ethan Furman <ethan at stoneleaf.us> wrote:
>
> > On 08/02/2013 03:52 PM, Andrew Barnert wrote:
> >> On Aug 2, 2013, at 13:18, Andrew McNabb <amcnabb at mcnabbs.org> wrote:
> >>
> >>> On Fri, Aug 02, 2013 at 01:37:58PM -0500, Brian Curtin wrote:
> >>>>
> >>>> Like everything else we add, shouldn't a module live in the Python
> >>>> ecosystem, standout as the best of breed, and *then* be proposed for
> >>>> inclusion?
> >>>
> >>> As Steven pointed out, numpy/scipy are best of breed in the Python
> >>> ecosystem, but they're too "advanced" for inclusion in the standard
> >>> library.  There's room for a standard implementation, but the module
> >>> wouldn't be complex enough to require years of development outside the
> >>> standard library.
> >>
> >> Years of development, no. But a few months on PyPI (with people
pointing to it from places like python-list and StackOverflow) would
capture a lot wider experience and testing than just a discussion on this
list.
> >>
> >>
> >> Also, if it's reasonably possible to make the implementation work for
3.0-3.3 (or even 2.6-3.3) a PyPI module will remain useful as a
quasi-official backport even after acceptance in the stdlib.
> >>
> >> So, I don't think short-circuiting the process is a good idea unless
there's a really compelling reason to do so.
> >
> > The compelling reasons are listed in the PEP.  The two most important
in my mind are:
> >
> >  1) easy to get wrong if doing it DIY
> >
> >  2) not being able to access third-party code (or only with great pain)
>
> Those are definitely compelling reasons for the module to _exist_, but
not compelling reasons to avoid the normal process for getting it into the
stdlib.
>
> Is there any reason to believe that this module would not benefit from
wider exposure and use before finalizing it? Is it so urgent that we can't
afford to wait for that to happen? Is it inappropriate for PyPI for some
reason?

Yes: on PyPI, there's little reason to believe that anyone would choose
this over one of the more sophisticated options that isn't suitable for the
standard library. We did much the same thing when redesigning the ipaddress
API: because the changes were to benefit beginners rather than expects,
there was little chance the new API could compete with ipaddr and netaddr,
it was added directly.

Raymond made the call a while ago for a minimal stats library to fill the
gap between "roll your own broken version" and "use NumPy/SciPy", and
several of us agreed that was a good idea. Steven's PEP is ultimately a
response to that request.

Accordingly, I think this would be an appropriate use of the "provisional
API" status.

The PEP should cover this issue though, and explicitly call out the
proposed API as provisional (and perhaps more directly call out the genesis
of the idea).

It should also be made available for use with earlier versions of Python on
PyPI, but I don't consider that a gating criteria for inclusion.

Cheers,
Nick.

>
>
> _______________________________________________
> 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/20130803/61888386/attachment-0001.html>