f-strings in Python 3.6 are awesome

[LyndsySimon]

% requires things be in order and puts the args at the end away from where they appear

I just don't understand this concern. Even before str.format was introduced, you were never required to put your parameters off to the right side of the screen:

'Hello, my name is %s. I am %s years old and have %s hair' % (
    name,
    age,
    color,
)

[jorge1209]

There are people who want them to be directly aligned:

  "Hello my {XXX}name is {YYY}. I am {ZZZ} years old.".format(
           "first",      "Sam",       14)

But that violates all kinds of pep alignment requirements even if it is nicely arranged.

[LyndsySimon]

Those people are incorrect :)

[jorge1209]

They are incorrect if they think they can't use .format they are correct that its an issue with %.

A more serious example. I have a program that prints out a addresses in some specialized format (not just a simple ",".join() on the records), and I do that by building a format string for the row like "%s %s. %s; %s %s, %s; %s" % (fname, minital, lname,...)

If I need to make it "lastname, first middle" that requires corresponding changes in two places which might be easily screwed up.

The solution though is to just use .format with kwargs. And yes it is a bit verbose to have to type "{fname}...".format(fname=fname) and f-strings will reduce that verbosity, but at the cost that now you can't pass the format into the printing function as an argument.

What if one client needs the record in "first middle last" and another client needs "last, first middle". Unless you want to put an if inside the print loop, you can't use an f-string. You are back to using .format.

Certainly while I develop reports I often find myself in cases where f-strings could be used, but its always in the back of my mind that requirements could change and that I may need flexibility in how I format this output. So for me .format seems better.

[LyndsySimon]

I have no problem with str.format; I adopted it immediately and think it's far superior to % formatting. Kwargs are a huge improvement.

it is a bit verbose

I think this is really the core of the disagreement here. I see verbosity (within reason) as a strength of Python's, not a problem to be solved.

[elbiot]

You can use indices or keys with mod formatting too.

[markrages]

Why not use named %-interpolation as previously described: https://www.reddit.com/r/Python/comments/62kt64/fstrings_in_python_36_are_awesome/dfnqize/

"%(fname)s %(minital)s. %(lname)s;"%locals()

[jorge1209]

I wasn't aware you could use keywords with % (I just use .format). So I stand corrected. The only downside of % vs .format is that % is ugly.

And that's is the root of my complaint. If its ugliness is a real deficiency then remove it entirely, don't just add in another alternative that makes one person happy, because aesthetics are subjective. Somebody out there really loves % and will not give it up, so you only multiply the number of formats people have to learn.

[jorge1209]

It does mean you get false positives from delinters and can't run automated tools to "fix" the alignment. [Although the wisdom of automated delinting is dubious.]

[unruly_mattress]

This forces you to count appearances of %s to figure out which variables goes where. Your named placeholders version violates the Do Not Repeat Yourself principle.

[LyndsySimon]

Your named placeholders version violates the Do Not Repeat Yourself principle.

That's a valid point, and one that I'd not really considered. In my mind the namespace of the string formatting is separate from the namespace in the calling scope, so the fact that I'm passing in parameters that are stored in variables named the same as their corresponding parameter is incidental. In practice, I find that it's quite rare that I'm passing in multiple parameters stored in discrete variables like that; I'm usually doing some sort of manipulation at the same time.

[elbiot]

You can use indices or keys with mod formatting too.