[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