[Python-Dev] Optimized string concatenation

[Guido van Rossum]

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