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

Oscar Benjamin oscar.j.benjamin at gmail.com
Wed Aug 7 13:10:40 CEST 2013


On Aug 6, 2013 11:19 PM, "Andrew Barnert" <abarnert at yahoo.com> wrote:
>
> On Aug 6, 2013, at 12:44, Michele Lacchia <michelelacchia at gmail.com>
wrote:
>>
>> Yes but then you lose all the advantages of iterators. What's the point
in that?
>> Furthermore it's not guaranteed that you can always converting an
iterator into a list. As it has already been said, you could run out of
memory, for instance.
>
> And the places where the stdlib/builtins do that automatic
conversion--even when it's well motivated and almost always harmless once
you think about it, like str.join--are surprising to most people.
(Following up on str.join as an example, just about every question whose
answer is str.join([...]) ends up with someone suggesting a genexpr instead
of a listcomp, someone else explaining that it doesn't actually save any
memory in that case, just wastes a bit of time, then some back and forth
until everyone finally gets it.)
>
> The question is whether it would be even _more_ surprising to return an
error, or a less accurate result. I don't know the answer to that.

I'm going to make the claim (with no supporting data) that more than 95% of
the time, when a user calls variance(iterator) they will be guilty of
premature optimisation. Really the cases where you can't build a collection
are rare. People will still do it though just because it's satisfying to do
everything with iterators in constant memory (I'm often guilty of this kind
of thing). However unlike str.join there's no one pass algorithm that can
be as accurate so it's not purely a performance question.

An error can inform users that a one pass API exists and the documentation
for the one pass API can explain that it is less accurate. That way the
user is properly informed of the tradeoffs and can respond appropriately
(or inappropriately!).

Oscar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130807/59929462/attachment.html>


More information about the Python-ideas mailing list