[Python-Dev] Re: [Python-checkins] python/dist/src/Python bltinmodule.c, 2.292.10.1, 2.292.10.2

Guido van Rossum guido at python.org
Sat Oct 25 23:26:03 EDT 2003


> > > changed builtin_sum to use PyNumber_InPlaceAdd -- unchanged semantics but
> > > fixes performance bug with sum(lotsoflists, []).
> >
> > I think this ought to be reverted, both in 2.3 and 2.4.  Consider this
> > code:
> 
> I have reverted it; it's obviously true that, by causing side effects on the 
> 2nd argument, the fix as I had commited it could change semantics.  I
> apologize for not thinking of this (and adding the missing unit-tests to
> catch this, see next paragraph).
> 
> If it was up to me I would still pursue the possibility of using 
> PyNumber_InPlaceAdd, for example by only doing so if the second
> argument could first be successfully copy.copy'ed into the result and falling 
> back to PyNumber_Add otherwise.  The alternative of leaving sum as a
> performance trap for the unwary -- an "attractive nuisance" in legal terms --
> would appear to me to be such a bad situation, as to warrant such
> effort (including adding unit-tests to ensure sum does not alter its second
> argument, works correctly with a non-copyable 2nd argument, etc).
> 
> However, it's YOUR decision, and you have already made it clear in
> another mail that your objections to remedying this performance bug are
> such that no possible solution will satisfy them.  If a type gives different
> results for "a = a + b" vs "a += b", there is no way sum can find this out;
> and while, were it my decision, I would not care to support such weird
> cases at such a huge performance price, it's not my decision.  Similarly
> for types which let you do "a = copy.copy(b)" but do NOT return a valid
> copy of b, or return b itself even though it's mutable, and so on weirdly.
> 
> I'm just very sad that I didn't think of this performance-trap back when
> the specs of sum were first being defined.  Oh well:-(.

Oh, but we all *did* think of it.  For strings. :-)

> Can I at least add
> a warning about this performance trap to the docs at
> http://www.python.org/doc/current/lib/built-in-funcs.html ?

Definitely.

You know, I don't even think that I would consider using sum() if I
wanted to concatenate a bunch of lists.  Let's use sum() for numbers.
Big deal.

--Guido van Rossum (home page: http://www.python.org/~guido/)




More information about the Python-Dev mailing list