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!
Yes it was. You know I am interested in this kind of decision (otherwise you'd have just checked it in) so you should have left the honor to me.
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.
That's a much more obscure case. The string concatenation hack will affect a significant fraction of all code.
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.
And in 99% of those cases nobody cares about performance. --Guido van Rossum (home page: http://www.python.org/~guido/)