<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 01/30/2014 05:27 PM, Steven D'Aprano
      wrote:<br>
    </div>
    <blockquote cite="mid:20140131012705.GF3799@ando" type="cite">
      <pre wrap="">I'm hesitant to require two passes over the data in _sum. Some 
higher-order statistics like variance are currently implemented using 
two passes, but ultimately I've like to support single-pass algorithms 
that can operate on large but finite iterators.

But I will consider it as an option.

I'm also hesitant to make the promise that _sum will be 
order-independent. Addition in Python isn't: [...]</pre>
    </blockquote>
    <br>
    I concede that this is mostly outside my expertise, and the
    statistics module and the PEP were your doing.  So you're the expert
    here and I will defer to you.<br>
    <br>
    But.  My dim understanding of the *whole point* of the new
    statistics module was that it valued correctness over raw
    performance.  I assumed sorting values from small to large** before
    summing was *exactly* the sort of thing it was written to do.  If
    all we wanted were Python's existing semantics, why bother writing
    statistics._sum() in the first place?  Just use sum().<br>
    <br>
    On the other hand, I had missed the fact that this was an
    internal-only method.  If changing _statistics._sum so it reordered
    the iterable to preserve correctness wouldn't change the behavior of
    any supported external APIs, then obviously there's no need, and I'd
    prefer to leave it alone for 3.4.  If you decided to change it for
    3.5 and people were relying on its old behavior, that would be on
    them.  (Though a comment saying "I might change this later" would be
    welcome... if true.)<br>
    <br>
    <br>
    <blockquote cite="mid:20140131012705.GF3799@ando" type="cite">
      <pre wrap="">If you're worried about people coming to rely on this, and thus running 
into trouble in the future if Counters get treated specially for (say) 
weighted data, then I'd accept a warning in the docs, or even a runtime 
warning. But not an exception.
</pre>
    </blockquote>
    <br>
    The statistics module isn't marked as provisional.  So the semantics
    that ship with 3.4 are going to be set in stone.  Changing them
    later simply won't be an option--that will break code.  If you want
    to treat Counter objects differently in the future than you do now,
    then I agree with Wolfgang: the best course of action would be to
    add an exception now.  But again I'll defer to your judgment about
    what's best for your module.<br>
    <br>
    <br>
    <i>/arry</i><br>
    <br>
    ** Or high-precision to low-precision.  You know what I mean, the
    classic "if you add large numbers first you throw away precision and
    can wind up with a different result" thing.<br>
  </body>
</html>