On Wed, Mar 28, 2018 at 06:27:19PM +0300, Serhiy Storchaka wrote:
- Change the semantic of f-strings. Make it closer to the semantic of
str.format(): evaluate all subexpressions first than format them. This can be implemented in two ways:
2a) Add additional instructions for stack manipulations. This will slow down f-strings.
2b) Introduce a new complex opcode that will replace FORMAT_VALUE and BUILD_STRING. This will speed up f-strings.
If the aim here is to be an optimization, then I vote strongly for 2b.
That gives you *faster f-strings* that have the same order-of-evaluation of normal method calls, so that when you optimize str.format into an f-string, not only is the behaviour identical, but they will be even faster than with option 3.
Python's execution model implies that
should fully evaluate both expressions before they are passed to the method. Making str.format a magical special case that violates that rule should be a last resort.
In this case, we can have our cake and eat it too: both the str.format to f-string optimization and keeping the normal evaluation rules. And as a bonus, we make f-strings even faster.
I say "we", but of course it is Serhiy doing the work, thank you.
Is there a down-side to 2b? It sounds like something you might end up doing at a later date regardless of what you do now.