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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4