On Sun, Mar 29, 2020 at 10:58 AM Paul Sokolovsky <pmiscml@gmail.com> wrote:
[SNIP]
1. Succumb to applying the same mis-optimization for string type as CPython3. (With the understanding that for speed-optimized projects, implementing mis-optimizations will eat into performance budget, and for memory-optimized projects, it likely will lead to noticeable memory bloat.) [SNIP]
1. The biggest "criticism" I see is a response a-la "there's no problem with CPython3, so there's nothing to fix". This is related to a bigger questions "whether a life outside CPython exists", or put more formally, where's the border between Python-the-language and CPython-the-implementation. To address this point, I tried to collect performance stats for a pretty wide array of Python implementations.
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. And I'm not sure if you're trying to insinuate that CPython represents Python the language and thus needs to not optimize for something other implementations have/can not optimize for, which if you are suggesting that then I have an uncomfortable conversation I need to have with PyPy 😉. Or if you're saying CPython and Python should be considered separate, then why can't CPython optimize for something it happens to be positioned to optimize for that other implementations can't/haven't?