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