On Mar 30, 2020, at 10:01, Brett Cannon <brett@python.org> wrote:
I don't think characterizing this as a "mis-optimization" is fair. There is use of in-place add with strings in the wild and CPython happens to be able to optimize for it. Someone was motivated to do the optimization so we took it without hurting performance for other things. There are plenty of other things that I see people regularly that I don't personally think is best practices but that doesn't mean we should automatically ignore them and not help make their code more performant if possible without sacrificing best practice performance.
Yes. A big part of the reason there’s so much use in the wild is that for small cases that aren’t in the middle of a bottleneck, it’s perfectly reasonable for people to add two or three strings and not care about performance. (Who cares about N**2 when N<=15 and it happens at most 4 times per run of your program?) So people do it, and it’s fine. When they really do need to optimize, a quick search of the FAQ or StackOverflow or whatever will tell them the right way to do it, and they do it, but most of the time it doesn’t matter. So when CPython at some point optimized str concatenation and made a bunch of scripts 1% faster, most people didn’t notice, and of course they wouldn’t have complained if they had. Maybe the OP could argue that this was a bad decision by finding examples of code that actually relies on that optimization despite being intended to be portable to other implementations. It’s worth comparing the case of calling sum on strings—which is potentially abused more often than used harmlessly, so instead of optimizing it, CPython made it an error. But without any such known examples, it’s hard not to call the string concatenation optimization a win.