<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Sorry for the bike shedding here, but:</div><div><br></div><blockquote type="cite"><p dir="ltr">The quadratic behaviour of repeated str summation is a subtle, silent error.</p>
</blockquote><div>OK, fair enough. I suppose it would be hard and ugly to catch those instances and raise an exception pointing users to "".join.</div><blockquote type="cite"><p dir="ltr">*is* controversial that CPython silently optimises some cases of it away, since it can cause problems when porting affected code to other interpreters that don't use refcounting and thus have a harder time implementing such a trick.</p>
</blockquote><div>Is there anything in the language spec that says string concatenation is O(n^2)? Or for that matter any of the performs characteristics of build in types? Those striker as implementation details that SHOULD be particular to the implementation.</div>
<div><br></div><div>Should we cripple the performance of some operation in Cpython so that it won't work better that Jython? That seems an odd choice. Then how dare PyPy make scalar computation faster? People might switch to cPython and not know they should have been using numpy all along...</div>
<div><br></div><blockquote type="cite">
<p dir="ltr">It's considered worth the cost, since it dramatically improves the performance of common naive code in a way that doesn't alter the semantics.</p></blockquote><div>Seems the same argument could be made for sum(list_of_strings).</div>
<blockquote type="cite">
<p dir="ltr">
> It seems pretty pedantic to say: we could make this work well, but we'd<br>
> rather chide you for not knowing the "proper" way to do it.</p>
<p dir="ltr">Yes, that's exactly what this is - a nudge towards the right way to concatenate strings without incurring quadratic behaviour.</p></blockquote><div>But if it were optimized, it wouldn't incur quadratic behavior.</div>
<blockquote type="cite"><p dir="ltr"> We *want* people to learn that distinction, not sweep it under the rug.</p></blockquote><div>But sum() is not inherently quadratic -- that's a limitation of the implementation. I agree that disallowing it is a good idea given that behavior, but if it were optimized, there would be no reason to steer people away.</div>
<div><br></div><div>"".join _could_ be naively written with the same poor performance -- why should users need to understand why one was optimized and one was not?</div><blockquote type="cite"><p dir="ltr"> That's the other reason the implicit optimisation is controversial - it hides an important difference in algorithmic complexity from users.</p>
</blockquote><div>It doesn't hide it -- it eliminates it. I suppose it's good for folks to understand the implications of string immutability for when they write their own algorithms, but this wouldn't be considered a good argument for a poorly performing sort() for instance.</div>
<blockquote type="cite">
<p dir="ltr">> Practicality beats purity?</p>
<p dir="ltr">Teaching users the difference between linear time operations and quadratic ones isn't about purity, it's about passing along a fundamental principle of algorithm scalability.</p></blockquote><div>That is a very import a lesson to learn, sure, but python is not only a teaching language. People will need to learn those lessons at some point, this one feature makes little difference. </div>
<blockquote type="cite">
<p dir="ltr">We do it specifically for strings because they *do* have an optimised algorithm available that we can point users towards, and concatenating multiple strings is common.</p></blockquote><div>Sure, but I think all that does is teach people about a cpython specific implementation -- and I doubt naive users get any closer to understanding algorithmic complexity -- all they learn is you should use string.join(). </div>
<div><br></div><div>Oh well, not really that big a deal.</div><div><br></div><div>-Chris</div></body></html>