Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PEP 450: Adding A Statistics Module To The Standard Library

python.org

Post reply on HN
Print view View original

41–50 of 85 posts

Re: PEP 450: Adding A Statistics Module To The Standard Library

#41

Post by pmr_ »

clutchski wrote: post #20

Batteries included is a fine philosophy when starting a language to encourage early adoption, but at this point, I don't think it's worth adding new libraries to the stdlib. Here's why: - It's very easy to find and install third party modules - Once a library is added to stdlib, the API is essentially frozen. This means we can end up stuck with less than ideal APIs (shutil/os, urllib2/urrlib, etc) or Guido & co are s…

There is a different perspective on the frozen APIs. Using an API from the stdlib gives you the certainty that your program is not going to break with a minor python version bump. This might not matter for all software but is crucial for others.

Re: PEP 450: Adding A Statistics Module To The Standard Library

#42

Post by keeperofdakeys »

ot wrote: post #39
daGrevis wrote: post #30

Earlier quoted context omitted.

Technically speaking, they are separate URLs that may lead to separate resources. For example, Google engine treats them as separate URLs. That's the reason why opening http://www.python.org/dev/peps/pep-0450 redirects to http://www.python.org/dev/peps/pep-0450/ . HN engine should follow redirect to avoid situations like this.

Technically speaking, there are no equivalent URLs in general, different strings may lead to different resources. Still, there are a number of common sense heuristics to normalize URLs, that HN applies to do de-duplication. I was wondering what is the rationale for not having trailing slash removal among them. I mean, is there any legitimate website that serves a different resource if you remove the trailing slash?

Without actually checking redirects, not breaking a few edge cases is much better than a few submissions being duplicated.

Re: PEP 450: Adding A Statistics Module To The Standard Library

#43

Post by zeckalpha »

ot wrote: post #39
daGrevis wrote: post #30

Earlier quoted context omitted.

Technically speaking, they are separate URLs that may lead to separate resources. For example, Google engine treats them as separate URLs. That's the reason why opening http://www.python.org/dev/peps/pep-0450 redirects to http://www.python.org/dev/peps/pep-0450/ . HN engine should follow redirect to avoid situations like this.

Technically speaking, there are no equivalent URLs in general, different strings may lead to different resources. Still, there are a number of common sense heuristics to normalize URLs, that HN applies to do de-duplication. I was wondering what is the rationale for not having trailing slash removal among them. I mean, is there any legitimate website that serves a different resource if you remove the trailing slash?

Or it could check for a 3xx HTTP status.

Re: PEP 450: Adding A Statistics Module To The Standard Library

#44

Post by enalicho »

lutusp wrote: post #18

Great idea, but while assembling this library, don't leave out permutations, combinations, and the binomial Probability Mass Function (PMF) and Cumulative Distribution Function (CDF). Small overhead, easy to implement, very useful. More here: http://arachnoid.com/binomial_probability

Permutations and combinations already exist within the itertools module.

Re: PEP 450: Adding A Statistics Module To The Standard Library

#45

Post by mistercow »

cdavid wrote: post #33
bachback wrote: post #32

Earlier quoted context omitted.

This is what I don't understand at all. Imagine somebody in a different area of computing would say: oh, we solved that 30 years ago and now there is no room for improvement at all? why can't this be done at least in C?

There is room for improvement, and it gets improved all the time (e.g. openblas is a recent contender). LAPACK is essentially an API for linear algebra, which is what allowed people to improve implementations and to benefit from them in older programs. Think of it as the C library of numerical computing.

I'm confused how a library written in Fortran 90 can be called "the C library of numerical computing".

Re: PEP 450: Adding A Statistics Module To The Standard Library

#46

Post by gsnedders »

ot wrote: post #39
daGrevis wrote: post #30

Earlier quoted context omitted.

Technically speaking, they are separate URLs that may lead to separate resources. For example, Google engine treats them as separate URLs. That's the reason why opening http://www.python.org/dev/peps/pep-0450 redirects to http://www.python.org/dev/peps/pep-0450/ . HN engine should follow redirect to avoid situations like this.

Technically speaking, there are no equivalent URLs in general, different strings may lead to different resources. Still, there are a number of common sense heuristics to normalize URLs, that HN applies to do de-duplication. I was wondering what is the rationale for not having trailing slash removal among them. I mean, is there any legitimate website that serves a different resource if you remove the trailing slash?

Per RFC3986/7, http://example.com/%60 and http://example.com/a are equivilant. (Indeed, all major browsers will request the latter regardless of what is input.) Equally, punycode encoded IRIs and the original IRI are equivilance. There is a whole section on equivilance in both of the RFCs (3967 includes 3986 by reference, so is a superset).

Re: PEP 450: Adding A Statistics Module To The Standard Library

#47

Post by rkangel »

cabalamat wrote: post #15

> For many people, installing numpy may be difficult or impossible. For example, people in corporate environments may have to go through a difficult, time-consuming process before being permitted to install third-party software. I do not regard this as a good justification for putting something in the standard library! If you don't have root access, use vitualenv (which you might want to do anyway) and install the pa…

Never under-estimate how much more helpful it can be to have something in a standard library. I do a lot of embedded development, and we have Python scripts all over the place on various embedded targets to perform all sorts of functions. Often it is incredibly inconvenient, expensive or even impossible to install extra packages on those machines, due to lack of permissions, lack of bandwidth, lack of time, or even a read only form of disk to name but a few reasons.

If your work involves a lot of scientific computing then yes, you're going to need numpy but if you're just updating an existing script that's doing some performance monitoring, having an accurate version of mean and standard deviation available seems like a great idea.

Python attempts to be batteries included, this is part of its philosophy and one of the reasons for its popularity. I'm glad this is being extended into a new area.

Re: PEP 450: Adding A Statistics Module To The Standard Library

#48

Post by gsnedders »

asgard1024 wrote: post #22
mvanveen wrote: post #13

Earlier quoted context omitted.

numpy has all sorts of awful C bindings which make it less than versatile in environments where you want pure Python. It's great from a performance point of view, but horrible for compatibility. Google App Engine used to suffer because of this (more specifically, it still only restricts your runtime to pure Python, but now you can import numpy at least). I believe the PyPy folks have also had their own set of struggl…

How does that work for SQLite 3, which _is_ part of Python library? I would actually prefer to have numpy included before those statistics functions.

PyPy has its own implementation of the sqlite module based on CFFI, as well as other stdlib modules that wrap C libraries (a lot of the libraries written in C for the sake of performance in CPython are just pure Python in PyPy — CPython normally includes both pure Python and not in those cases). numpy is far more complex because it's a far bigger API than anything like sqlite, though work is progressing on it.

Re: PEP 450: Adding A Statistics Module To The Standard Library

#49

Post by cdavid »

bachback wrote: post #34
cdavid wrote: post #28

Earlier quoted context omitted.

numpy is quite portable, I am not sure what you mean by not nearly portable enough. The reason why you can't do pip install numpy is pip's fault, there is nothing that numpy can do to make that work. Note that easy_install numpy does work on windows (without the need for a C compiler).

the problems I have had with numpy are endless. Usually I'll just prefer to write my own, because it's quicker. if you have tried to get numpy running on a cloud machine you'll know what I'm talking about. basically you will have to know how to compile from source, know some gcc, etc. the last time I tried to get it running I promised myself never to use numpy again.

many people have been able to use numpy on clouds. You only need gcc and the python-dev package on linux.

Frankly, building numpy is not very complicated (scipy is a bit complicated, and only if you are not on linux).

Re: PEP 450: Adding A Statistics Module To The Standard Library

#50

Post by cdavid »

dalke wrote: post #35
aidos wrote: post #16

Earlier quoted context omitted.

You wouldn't write your own - numpy / scipy have everything you'll need.

Some of the things I need are: - fewer dependencies for my package I've written the average() and standard_deviation() functions at least a couple of dozen times, because it doesn't make sense to require numpy in order to summarize, say, benchmark timing results. - reduced import time NumPy and SciPy were designed with math-heavy users in mind, who start Python once and either work in the REPL for hours or run non-tr…

scipy.stats distribution objects are a bit particular, that's a bit unfair to pin point them.

Generally, numpy and scipy have much better docstrings than python stdlib itself.

Post reply on HN