Home Original page

[Python-Dev] Re: accumulator display syntax

Alex Martelli aleaxit at yahoo.com
Sat Oct 25 19:11:51 EDT 2003 
On Saturday 25 October 2003 10:20 pm, Guido van Rossum wrote:
> > sum looks cooler, but it can be an order of magnitude slower
> > than the humble loop of result.extend calls.  We could fix this
> > specific performance trap by specialcasing in sum those cases
> > where the result has a += method -- hmmm... would a patch for
> > this performance bug be accepted for 2.3.* ...?  (I understand and
> > approve that we're keen on avoiding adding functionality in any
> > 2.3.*, but fixed-functionality performance enhancements should
> > be just as ok as fixes to functionality bugs, right?)
>
> No way.  There's nothing that guarantees that a+=b has the same
> semantics as a+b, and in fact for lists it doesn't.

You mean because += is more permissive (accepts any sequence
RHS while + insists the RHS be specifically a list)?  I don't see how
this would make it bad to use += instead of + -- if we let the user
sum up a mix of (e.g.) strings and tuples, why are we hurting him?

And it seemed to me that cases in which the current semantics of
"a = a + b" would work correctly, while the potentially-faster "a += b"
wouldn't, could be classified as "weird" and ignored in favour of
avoiding "sum" be an orders-of-magnitude performance trap for
such cases (see my performance measurements in other posts of
mine to this thread).

Still, you're the boss.  Sorry -- I'll immediately revert the commits I
had made and be less eager in the future.


> I wouldn't even want this for 2.4.

Aye aye, cap'n.  I'll revert the 2.4 commits too, then.  Sorry.


Alex
More information about the Python-Dev mailing list