On Oct 23, 2019, at 10:04, Christopher Barker email@example.com wrote:
This talk about optimization is confusing me:
The main argument for why “a b c”.split() is not good enough, and therefore we need a new syntax, is that it’s “too slow”.
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.
The reason I thought you were adding onto that argument is that you said people should be able to write something and know it’ll be _efficient_ on every Python implementation. Why does efficient matter if this code will only show up in places where you are, as you say below, already not concerned with performance?
That’s what I was responding to. If that wasn’t your point, I apologize for misreading it.
These are literals -- they should only get processed once, generally on module import.
If you are putting a long list of literal strings inside a tight loop, you are already not concerned with performance.
Performance is absolutely the LAST reason to consider any proposal like this.
I agree. That’s why I think “too slow” isn’t a good argument, and to the tiny extent that it is, “then let’s write an optimizer for the already-common idiom” is a good answer, not “let’s come up with a whole new syntax that does the same thing”.