> 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/)
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