[Python-Dev] Usage of += on strings in loops in stdlib

[Ned Batchelder]

On 2/12/2013 4:16 PM, Brett Cannon wrote:
>
>
>
> On Tue, Feb 12, 2013 at 4:06 PM, Antoine Pitrou <solipsis at pitrou.net 
> <mailto:solipsis at pitrou.net>> wrote:
>
>
>     Hi !
>
>     On Tue, 12 Feb 2013 23:03:04 +0200
>     Maciej Fijalkowski <fijall at gmail.com <mailto:fijall at gmail.com>> wrote:
>     >
>     > We recently encountered a performance issue in stdlib for pypy. It
>     > turned out that someone commited a performance "fix" that uses
>     += for
>     > strings instead of "".join() that was there before.
>     >
>     > Now this hurts pypy (we can mitigate it to some degree though) and
>     > possible Jython and IronPython too.
>     >
>     > How people feel about generally not having += on long strings in
>     > stdlib (since the refcount = 1 thing is a hack)?
>
>     I agree that += should not be used as an optimization (on strings) in
>     the stdlib code. The optimization is there so that uncareful code does
>     not degenerate, but deliberately relying on it is a bit devilish.
>     (optimisare diabolicum :-))
>
>
> Ditto from me. If you're going so far as to want to optimize Python 
> code then you probably are going to care enough to accelerate it in C, 
> in which case you can leave the Python code idiomatic.

But the only reason "".join() is a Python idiom in the first place is 
because it was "the fast way" to do what everyone initially coded as "s 
+= ...".   Just because we all learned a long time ago that joining was 
the fast way to build a string doesn't mean that "".join() is the clean 
idiomatic way to do it.

--Ned.

>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ned%40nedbatchelder.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130212/128b69ff/attachment.html>