(original) (raw)
On 2/12/2013 4:16 PM, Brett Cannon wrote:
On Tue, Feb 12, 2013 at 4:06 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Hi !
I agree that += should not be used as an optimization (on strings) in
On Tue, 12 Feb 2013 23:03:04 +0200
Maciej Fijalkowski <fijall@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)?
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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ned%40nedbatchelder.com