[jojo14]

I don't mean to be rude, but what is the point ?

AFAIK the % operator is not deprecated. In fact % formatting being syntactically near identical to C is a feature to me. I use format strings as well depending on context.

% formatting being older doesn't mean it's obsolete.

That said it is cool to design a script to transform your code and any time you spent in the developing of automation is time earned.

[ktpsns]

Also keep in mind that localization (gettext) relies on run-time evaluation of the string argument. That's where % and .format shine, but f strings don't. Cf. https://stackoverflow.com/questions/49797658/how-to-use-gett...

[estebarb]

I worked with code generators that use extensively `.format` or `%`. The code of those generators is too difficult to follow. In my previous job I was able to rewrite from scratch over of those generators with saner jinja2 templates. But for inherited/external code that task is not always viable. So, f-strings bring the benefit of being clearer, while keeping the existing code.

[solveit]

>what is the point ?

I can see an in-house style guide strongly recommending f-strings over % formatting

[stigz]

Also can improve performance.

[solveit]

Sure, but how often is string formatting the bottleneck on performance?

[greatgib]

Do you have a proof of that? I think that it might be the opposite.

[BerislavLopac]

F-strings are much faster:

    In [4]: a, b, c, d = ("123", "456", "789", "0ab")

    In [5]: %timeit a + "-" + b
    139 ns ± 10 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

    In [6]: %timeit "%s-%s" % (a, b)
    198 ns ± 13.8 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

    In [7]: %timeit "{}-{}".format(a, b)
    248 ns ± 9.17 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

    In [8]: %timeit f"{a}-{b}"
    99 ns ± 2.48 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

    In [9]: %timeit  a + "-" + b + "-" + c + "-" + d
    344 ns ± 10.3 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

    In [11]: %timeit "%s-%s-%s-%s" % (a, b, c, d)
    290 ns ± 9.64 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

    In [12]: %timeit ''.join([a, '-', b, '-', c, '-', d])
    245 ns ± 2.32 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

    In [13]: %timeit "{0}-{1}-{2}-{3}".format(a, b, c, d)
    471 ns ± 23.6 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

    In [14]: %timeit f"{a}-{b}-{c}-{d}"
    176 ns ± 11.9 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

[yunruse]

It’s not a proof, but it makes logical sense: f-strings can be noted and compiled at runtime, whereas regular strings must be compiled every time string.format notices them. Maybe middling on one run, but reasonably useful in a long loop

[kelsolaar]

We have quite large codebases that I’m inclined to convert to f-Strings because it is much more compact and elegant than the % and .format variants.

[pjmlp]

I also miss the point, yak shaving spending development money in worthless code rewriting, with zero business value.

[ed_balls]

performance and % can cause problems with tuples https://stackoverflow.com/questions/1455602/printing-tuple-w...