Hm, without thinking too much about it I'd say it's okay to change the evaluation order. Can these optimizations be disabled with something like -O0?
On Wed, Mar 28, 2018 at 8:27 AM, Serhiy Storchaka storchaka@gmail.com wrote:
There is a subtle semantic difference between str.format() and "equivalent" f-string.
'{}{}'.format(a, b) f'{a}{b}'In the former case b is evaluated before formatting a. This is equivalent to
t1 = a t2 = b t3 = format(t1) t4 = format(t2) r = t3 + t4In the latter case a is formatted before evaluating b. This is equivalent to
t1 = a t2 = format(t1) t3 = b t4 = format(t3) r = t2 + t4In most cases this doesn't matter, but when implement the optimization that transforms the former expression to the the latter one ([1], [2]) we have to make a decision what to do with this difference.
- Keep the exact semantic of str.format() when optimize it. This means
that it should be transformed into AST node different from the AST node used for f-strings. Either introduce a new AST node type, or add a boolean flag to JoinedStr.
- 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.
- Transform str.format() into an f-string with changing semantic, and
ignore this change. This is not new. The optimizer already changes semantic. Non-optimized "if a and True:" would call bool(a) twice, but optimized code calls it only once.
[1] https://bugs.python.org/issue28307 [2] https://bugs.python.org/issue28308
Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido% 40python.org