[Python-Dev] Subtle difference between f-strings and str.format()

[Nick Coghlan]

On 30 March 2018 at 03:33, Eric V. Smith <eric at trueblade.com> wrote:
> On 3/29/2018 12:13 PM, Nick Coghlan wrote:
>> 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.

Definitely 3.8+ only. The nice thing about doing this implicitly at
the compiler level is that it potentially provides an automatic
performance improvement for existing libraries and applications. The
justification for the extra complexity would then come from whether or
not it actually measurably improve things, either for the benchmark
suite, or for folks' real-world applications.

Steven D'Aprano also raises a good point on that front: a
FORMAT_STRING super-opcode that sped up f-strings *and* allowed
semantics preserving constant-folding of str.format calls on string
literals could make more sense than a change that focused solely on
the implicit optimisation case.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia