+ is a terrible operator for formating.

You got:

    price = 18.8
    date = datetime.datetime.now()

Now you want to save in a file:

    "It's 18.80 and we are the 01/04/2016"

With +:

    num, dec = str(price).split('.')
    msg = ("It's "+ num + "." + dec.ljust(2, '0') + 
          " and we are the " + date.strftime("%m/%d/%Y") + "\n")
    f.write(msg)

It is so long and ugly we have to break it on several lines to respect PEP8.

And it's a pain to write, or even worst, to read.

With print():

    num, dec = str(price).split('.')
    print("It's", num, ".", dec.ljust(2, '0'), 
          " and we are the ", date.strftime("%m/%d/%Y")), file=f)   

A tiny bit better since we don't have to use that many concatenation tricks.

If we didn't have to format the float, print() would have converted it to string for us which is nice (with + you have to call str() all the time).

With "%":

    f.write("It's %.2f and we are the %s\n" % (price, date.strftime("%m/%d/%Y")))

Way better, but still hard to read.

With format():

    f.write("It's {:.2f} and we are the {:%m/%d/%Y}\n".format(price, date))

Now we are getting sometwhere...

With fstrings:

    f.write("It's {price:.2f} and we are the {date:%m/%d/%Y}\n")

fstrings have everything:

    - easier / faster to type than any other versions;
    - easier to read than any other versions;
    - as expressive as any other versions.

It's reduce work by making you think less, type faster, read faster (for you and your colleague) and it's easier to spot bugs.

The only place where you don't want fstring are for l10n.

I don't think it's even that bad for l10n, as you can treat the expression-like format specifiers as opaque keywords for the placeholders.

For example, your i18n tool can extract:

    "It's {price:.2f} and we are the {date:%m/%d/%Y}\n"

as a key, and then l10n can map this to:

    fr_FR: "C'est {price:.2f} et nous sommes le {date:%d/%m/%Y}\n"

(Here we can fix up the silly US date formatting, too, although really you shouldn't be localising dates in your format strings).

All that remains is for them to work out some way of mapping in that localised string, as you can do this:

    _("It's {price:.2f} and we are the {date:%m/%d/%Y}\n").format(price=price, date=date)

any more.

> (Here we can fix up the silly US date formatting, too, although really you shouldn't be localising dates in your format strings).

ISO 8601 (similar to Japanese format) is the most logical way to format dates: YYYY-MM-DD, easily sortable, not the silly way US and Europeans format their dates. ;)

https://xkcd.com/1179/

Date formatting preferences are done at the desktop level and apps should query for it. All frameworks I can think of have a way of doing so, and you can just tell them "I want a long-form date & time", "I want a short date", "I want a short non-numeric date".

If you are a fan of ISO8601 (which I am), you can then set this globally on your desktop, rather than expect the app developers / translators to choose for you.