On Wed, Oct 23, 2019 at 10:04:36AM -0700, Christopher Barker wrote:
I'm not saying that things like this shouldn't be optimized -- faster import is a good thing, but I am saying it's not a reason to add a language feature.
I'm not sure why import is relevent here. We're not saying that performance is the only or even primary reason to add this feature. Shifting the processing from runtime to compile time is just icing on the cake. The proposal is for a less error-prone, easier to write and read way to express the programmer's intent to generate a list of single-word string literals. The current "obvious" solution is tedious, annoying, verbose (about a third longer than it need be) and error-prone.^1 It is so sub-optimal that some people resort to writing editor macros to write lists of words for them. Fine for those with the right skills and editor to do this, but not so great for the rest of us. The alternative solution using split() is less tedious, but it's contentious (some people think using split() is a hack) and shifts the work from compile-time to run-time, a pessimation.^2 ^1 I'm gratified to see that nobody yet has noticed the error in my earlier example involving the strings 'zero' through 'thirty', which supports my point that the status quo is sub-optimal. ^2 On my computer the split idiom is about forty percent slower: $ ./python -m timeit "['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h']" 200000 loops, best of 5: 1.44 usec per loop $ ./python -m timeit "'a b c d e f g h'.split()" 100000 loops, best of 5: 2.05 usec per loop so it's not a trivial slowdown, even if this is unlikely to be a bottleneck in many programs. -- Steven