On Oct 23, 2019, at 22:45, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Andrew Barnert via Python-ideas wrote:
Someone earlier in this thread said we could optimize calling split on a string literal, just as we can and do optimize iterating over a list literal in a for statement. The counter argument—which I thought you were adding onto—is that this would be bad because it would make people write bad code for older/alternative Pythons.
There's a precedent for this kind of thing -- there's an optimisation for repeatedly concatenating onto a string in some circumstances, even though building a list and joining it is recommended if you want guaranteed good performance. So the fact that it wouldn't apply to all versions and implementations of Python shouldn't really matter.
I'm not sure how much it would really help, though. Lists being mutable, it would have to build a new list every time,
Sure, but a small number of LOAD_CONSTs and a BUILD_LIST has to be faster than 1 LOAD_CONST and a call to the split method. From testing some different random examples, the split takes anywhere from 1.8x to 3.9x as long, and I assume with longer element strings it would be even more of a difference. I still doubt this ever occurs anywhere near a bottleneck in real-life code—but if it did, it seems like the optimization would be worth it. (Assuming a better micro-benchmark verifies my quick&dirty test.)