On Oct 23, 2019, at 03:08, Steven D'Aprano <steve@pearwood.info> wrote:
>
> It could also be done by a source code preprocessor, or an AST
> transformation, without changing syntax.
>
> But the advantage of changing the syntax is that it becomes the One
> Obvious Way, and you know it will be efficient whatever version or
> implementation of Python you are using.

The advantage of just optimizing split on a literal is that split becomes the One Obvious Way, and you know it will work and be correct in whatever version of implementation of Python you are using, back to 0.9; it’ll just be faster in CPython 3.9+.

In fact, given that we already use split all over the place, and even offer shorthand for it in places like namedtuple, and people recommend it on python-list and StackOverflow without any pushback, I think it already is TOOWTDI for many cases. So why not optimize it?

And your argument is really an argument against adding any optimizations to CPython. The fact that nested tuple literals are now as fast as constants means someone could be constructing one right in the middle of a bottleneck, making their code appear to work on all Python versions and pass benchmarks in current CPython but then be unacceptably slow when they deploy on CPython 3.4 or uPython or whatever. But would you say that optimization was a mistake, and we should have instead left nested tuple displays slow and invented a new syntax for nested tuple constants that would make it an obvious SyntaxError in 3.4 or uPython, just because it’s possible that one person might run into that unacceptably slow case one day, even though nobody has ever complained about it?

And this is almost certainly the same thing. If someone has a case where they wrote out a long list of strings as a list literal with quotes instead of using split because benchmarking required it, where they would have been misled into using split if it were faster in 3.8 even though some of their deployment targets are 3.7, then we should listen. But I doubt anyone does. The optimization will just be a small QoI thing that adds to Python 3.9 being on average a bit faster than 3.8.

_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7F3FC3YR7XUG4CHXT27BXQAED7WR3F35/
Code of Conduct: http://python.org/psf/codeofconduct/