> > The SF patch http://www.python.org/sf/980695 about making repeated > string > > concatenations efficient has been reviewed and is acceptable on > technical > > grounds. This is about avoiding the quadratic behavior of > > > > s = '' > > for x in y: > > s += some_string(x) > > FWIW, I didn't approve it, Raymond did, IMO prematurely. :-( > > In the past similar schemes based on refcount were rejected because we > couldn't be sure that there wasn't C code with an uncounted > reference. Is that ruled out in this scheme? Yes it is. Unlike the refcount check proposed for PyList_Sort, Armin's patch only applies to the eval loop and cannot be called directly. I spent a *long* time reviewing and testing this patch. The code is clean. The concept works. It delivers significant, measurable benefits. The standard library itself has existing use cases. Every benchmark I tried showed results. The patch was not approved prematurely! On the off chance that Armin, Michael, and I missed a case, then including the patch in the second alpha is the best way to find it. > I am > going to make up a new rule here, and state that implementation > features that affect not just the running speed but the O() rate for > certain algorithms should be considered language features, because > any implementation will be required to implement them in order to > ensure code portability. Even list.sort() does not guarantee specific O() rates. Currently, the fastest way to write a merge(a,b) is sort(a+b). That relies on the current implementation recognizing that a and b are already sorted and doing a linear time concatenation. > Why do people want this so badly? Because the a=a+b form occurs everywhere, not just in newbie code. It is in the standard library, it shows up naturally in SAX, and it is often the most clear way to express an idea. Raymond
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