> 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. I wouldn't even want this for 2.4. --Guido van Rossum (home page: http://www.python.org/~guido/)
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