On 3/29/2018 12:13 PM, Nick Coghlan wrote:
On 29 March 2018 at 21:50, Eric V. Smith <e...@trueblade.com> wrote:
#1 seems so complex as to not be worth it, given the likely small overall
impact of the optimization to a large program. If the speedup really is
sufficiently important for a particular piece of code, I'd suggest just
rewriting the code to use f-strings, and the author could then determine if
the transformation breaks anything. Maybe write a 2to3 like tool that would
identify places where str.format or %-formatting could be replaced by
f-strings? I know I'd run it on my code, if it existed. Because the
optimization can only work code with literals, I think manually modifying
the source code is an acceptable solution if the possible change in
semantics implied by #3 are unacceptable.
While more projects are starting to actively drop Python 2.x support,
there are also quite a few still straddling the two different
versions. The "rewrite to f-strings" approach requires explicitly
dropping support for everything below 3.6, whereas implicit
optimization of literal based formatting will work even for folks
preserving backwards compatibility with older versions.
Sure. But 3.6 will be 3 years old before this optimization is released.
I've been seeing 3.4 support dropping off, and expect to see 3.5 follow
suit by the time 3.8 is released. Although maybe the thought is to do
this in a bug-fix release? If we're changing semantics at all, that
seems like a non-starter.
As far as the semantics go, perhaps it would be possible to explicitly
create a tuple as part of the implementation to ensure that the
arguments are still evaluated in order, and everything gets calculated
exactly once? This would have the benefit that even format strings
that used numbered references could be optimised in a fairly
straightforward way.
'{}{}'.format(a, b)
would become:
_hidden_ref = (a, b)
f'{_hidden_ref[0]}{_hidden_ref[1]}'
while:
'{1}{0}'.format(a, b)
would become:
_hidden_ref = (a, b)
f'{_hidden_ref[1]}{_hidden_ref[0]}'
This would probably need to be implemented as Serhiy's option 1
(generating a distinct AST node), which in turn leads to 2a: adding
extra stack manipulation opcodes in order to more closely replicate
str.format semantics.
I still think the complexity isn't worth it, but maybe I'm a lone voice
on this.
Eric.
_______________________________________________
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/archive%40mail-archive.com
