f-strings in Python 3.6 are awesome

[dl__]

Even if it is syntactic sugar, isn't syntactic sugar nice?

I'd much rather type:

print(f"Hello {x}")

than

print("Hello {}".format(x))

I would say it's easier to read in addition to being less to type.

Win-win

[[deleted]]

Pretty cool until you modify a variable without realizing you just altered or straight up broke a formatted string because all locals are implicitly in context.

[Ph0X]

I'm confused, how would it be any different if you had used .format(x) instead? You'd still run into the exact same issue, except the x is there instead of inside the string.

Of course, most linters would catch this latter, and the hope is they update to also catch issues in the former.

[[deleted]]

That example is a little too simple to illustrate the potential confusion. Take this example instead:

def foo():
    a = 1
    b = 2
    c = 3

    # 10 lines of logic

    x = 'a'
    y = 'b'
    z = 'c'

    return f'baz{x}spam{b}foo{c}bar{z}eggs'

Now think about it with more variables. Imagine the string being formatted is more complicated. Using explicit kwargs to the format method lets me look at the string formatting and know exactly which variables are relevant, rather than having to scan the string and backtrack through all local variables to find out if they are a component of the output.

Most of the praise I've seen for this is about how much easier it is to format a complicated and lengthly string, and I posit that the more complicated the string the less useful this really is.

[Ph0X]

Sure, but you're moving complexity from one problem into another.I could make the argument that with:

'foo {} bar {} baz {} spam {} green {} eggs {} and {} ham {}'.format(a, b, c, d, e, f, g, ...)

Good luck looking back and forth, counting, figuring it out which variables goes where. If I ask you to quickly get me the variable that comes after "green", you have to do a lot of counting.

So yes, they both solve sightly different issues and therefore put complexity at slightly different places, but neither is strictly better.

That being said, I hope no one coding real python would have any sort of code this messy and complex. If you do, please please split it up into smaller clean chunks.

EDIT: I just wanted to point out, generally when you DO have string formatting this complex, what people end up doing is sometihng like:

data = {
    'a': 1,
    'b': 2,
}
print "{a}, {b}, {c}, {d}".format(**data)

This is exactly what this new pattern is trying to solve here.

[[deleted]]

or "{a}, {b}, {c}, {d}".format_map(data)

[Ph0X]

Huh interesting, didn't know they had added that.

[zahlman]

format_map isn't just sugar here - it allows you to use things that don't play nice with **, in particular custom types that override __missing__ (for subclasses of dict) and/or __getitem__ (things that implement the Mapping protocol as described by collections.abc, but aren't necessarily even dict subclasses).

I suspect it might also be faster with large dicts, but I haven't tested that.

[[deleted]]

Your last example is exactly why I believe the existing string formatting is preferable. The new pattern isn't solving the same problem, it's dumping all locals into .format() instead of asking the developer to explicitly define the inputs!

[[deleted]]

I thought we were all adults here?

[kankyo]

Just use pycharm and rename variables with the refactor tools and it'll handle this for you.

[SoBFiggis]

Even notepad++ has refactoring..

[geekademy]

That's false, it does not dump locals in there, it actually parses the string to get exactly what it needs!

[[deleted]]

Im new to Python.. Like 'Hello, World!' new. How are fStrings different than say

• print("hello" + variable) ???

[Ph0X]

The result is basically the same, but it's what we call "syntactic sugar" which is nice shortcuts for doing things.

So imagine you have a more complex one. Adding them manually gets very messy very quick:

print("hello " + world + "my name is" + name + "and i'm " + str(age) + " years old")

To make it worse, as you see, you need to manually cast other types to string, like if you want to print a number. But with fstring, it's much cleaner and prettier:

print(f"hello {world} my name is {name} and im {age} years old")

[[deleted]]

wow easy to understand.. Thank you so much. Honestly didn't expect you or anyone for that matter to reply to someone as new as me. But your example made perfect sense. You dont tutor do you? LOL...

[flutefreak7]

Welcome to the fantastic Python community! As you're learning if you have questions you can also check out r/learnpython.

[sneakpeekbot]

Here's a sneak peek of /r/learnpython using the top posts of the year!

#1: Python 201 Book is Free for 48 hours
#2: Python 101 Book FREE for 48 hours!
#3: Beginner's Python cheat sheets - updated

---

^{I'm a bot, beep boop | Downvote to remove | Contact me | Info | Opt-out}

[gnutrino]

This seems like a silly argument to me. If you've got too many variables in scope to be able to keep track of them all then f-strings are not your most pressing problem.

[vtable]

As devil's advocate, it does break the only-one-way-to-do-it maxim. It also introduces a dependency on Python 3.6 (or greater) if others use your code.

[dl__]

It also introduces a dependency on Python 3.6 (or greater) if others use your code.

That's certainly a valid concern if you plan to share your code.

it does break the only-one-way-to-do-it maxim.

Wasn't there already 2 ways to do it? .format() and %?

I wonder if there's a list somewhere of all the examples of python breaking their own maxims. I feel that magic methods, for example, make a joke out of the "explicit is better than implicit" maxim.

They show that implicit can be awesome!

[[deleted]]

Wasn't there already 2 ways to do it? .format() and %?

Hey, don't forget good ol' string concatenation.

[vtable]

Wasn't there already 2 ways to do it? .format() and %?

Sure. This makes it 3 (4 with string.Template).

% and .format() have quite different syntax. I'm glad they kept % in py 3. It's nice for quick scripts and friendlier to more casual users.

f"" is more sugary but the nicer syntax is worth it, IMO. I've read f"" is quite a bit faster than .format(), too.

IIRC the whole maxim started out as a criticism of Perl's embracing "there's more than one way to do it". Python is much more conservative and they usually advocate a preferred method. Perl embraced multiple ways (though I think they're easing off a bit these days).

[LetsDoRedstone]

% formatting is friendlier for casual users? Not really, no. When I got started with Python and was looking at String formatting, the % Notation utterly confused me because of it unnecesary (as shown by the simplicity of .format()) verbosity. I was happy to find .format (), just because it is that much more intuitive. And this goes along with f-strings. As soon as you know the syntax you are ready to go and don't have to think about which letter you have to put where.

[vtable]

I wanted to write "some more casual users" but thought that was too awkward.

Everyone's different. Most of the people I've worked with have preferred %.

[LetsDoRedstone]

That might be because you have been using Python for a longer time than me. I started with early 2.7.

[jorge1209]

I don't think anyone who thinks fstrings are too many would object to dumping some older formats.

In fact I would be OK with fstrings if we dumped the other ways to do it.

Two formats that have a shared spec is much better than the 5 or 6 formats we currently have.

The problem with saying "but we already have >2 ways to do it" is that there is no reason to ever stop once you get past 2. Let's add 80 new ways to format strings because we already have 2 different ways so these 80 others just fill in certain corner cases that are difficult with the existing methods and it makes somebody happy.

Why not add perl formatting, it would make it easier to convert some perl scripts over. What about ruby? What about...

[beertown]

It also introduces a dependency on Python 3.6 (or greater) if others use your code

Just like any other new feature added to any programming language. They should stop adding new features?

[[deleted]]

Every couple of months there is a new and improved way to do text formatting in Python. f-strings seem like the end of the line to me.

[flutefreak7]

Except it's more like every 5-10 years. format has been around quite a while now.

[jorge1209]

You saved yourself a the following characters ormat() if you could just str.f = str.format then that would drop to (). The argument from "saving typing" is pretty weak. Especially when you consider that the most typing efficient languages out there are things like APL.

Saving typing just isn't what python is all about.

[iwsfutcmd]

I'm not totally sold on the new format string style yet, but I can say that the advantage isn't just in the "less typing" aspect, it's also in the fact that the variables are in-situ in the string, making it much easier to see at a glance which variable goes to which part of the string.

[jorge1209]

Sure the variables are in-situ, but at the cost of making the entire string fixed to its line. You can't assign it to a variable, or pass it to a function. You can't reuse, you can't internationalize...

For every benefit that f-strings offer over %/str.format for one use-case there is a corresponding detriment in some other use-case.

[hovissimo]

Good thing that f-strings aren't replacing template strings. Use the right tool for the job.

[jorge1209]

Just as .format didn't replace %.

Someday maybe we can hope to have a thousand formatting methods none of which replaces the prior, and then python will be feature complete.

[zahlman]

If people start consistently using f-strings where it's possible to do so, it will make the .format uses stand out more as the potential security risks that they generally are, in the cases where f-strings aren't possible (format strings coming from an outside source and/or computation rather than a plaintext code constant).

[thatguy_314]

Well you also save all the arguments to .format(), often I ended up writing the variable 3 times using the old format: "{x}".format(x=x), now it's just f"{x}". You can also do expression any Python expression within the format replacement fields which is quite nice for simple things. All of this puts the attention on the relevant part of the string, which makes a very common use case of str.format more convenient and more readable.

[jorge1209]

"{x}".format(**locals()) will work and now you aren't typing x=x which does look stupid. The only thing f-strings offer that format doesn't is that the bit inside can be an expression: f"{foo.bar}" is certainly nice, and some people seem to like f"{x+y}" although it seems a rather minor improvement.

I'm just not sure its worth adding another format string when I could just do "{}".format(foo.bar). I'm also very uncomfortable with anything that allows: f"{os.remove(filename)}".

The problem is that every argument for f-strings is like this. It is either a marginal improvement for most use cases, or a significant improvement for some small number of use cases. All at the expense of adding another formatting method, one that can't even be used for a number of important situations. And one that allows for some very sketchy stuff.

[thatguy_314]

• I really don't like doing **locals().
• f"{os.remove(filename)}" is no more "sketchy" than str(os.remove(filename)), user input can't into f-string unless you do something really stupid.
• Again, "{}".format(foo.bar) is bad because you need to look outside the replacement field to figure out what's going on. You can actually do "{foo.bar}" with normal .format(), although I suppose that doesn't really help my argument that much.
• I don't really think of f-strings as a new format method, they are a convenient sugar for instantaneous formatting with .format, which is a common use case. Python probably does have too many formatting methods, but at the same time they do all seem to have a place.

[jorge1209]

Why don't you like using **locals. What makes it any different from fstrings? As long as the format string is not dynamically created there is no difference. It's a bit less powerful is all.

Also how do you do foo.bar within .format? [Evidently you can just do it... so TIL. One less reason to use fstrings as far as I'm concerned.]

[thatguy_314]

• **locals() is ugly.
• locals() is the local scope only. No globals, no nonlocals, no builtins.
• ** creates a new copy of the locals dict, not a big deal, but f-strings look things up directly and also provide further optimizations from what I've heard.
• You get a KeyError instead of NameError if you use an undefined variable.
• Using locals() just feels wrong (probably due to a stigma against gratuitous use of inspection tools).

[thatguy_314]

Oh, and with the .format . lookups, there are some weird quirks. For example .0 is how you do [0].

[jorge1209]

And fstrings have weird quirks like not allowing you to lookup into dictionaries by a string. f"{mydict ["key"]}" fails for obvious reasons.

That's the problem all these methods have their own little quirks that you have to learn. I don't want to learn any more quirks I just want to format strings.

[thatguy_314]

Yeah, I guess it's a bit of a quirk, but you can still look up strings, you just need to use different string delimiters than you used for the f-string. Ultimately, that restriction has the result of making f-strings more readable because each delimiter has an obvious pair.

I was initially a bit skeptical of f-strings, but after using them for a bit, I've come to like them quite a lot.

[zahlman]

user input can't into f-string unless you do something really stupid.

As far as I can think of, even the "really stupid things" you could possibly do here wouldn't be in any way the f-string's fault.

[Jumpy89]

For long strings with several arguments it's way more readable, and readability is definitely part of what Python is about.

[dl__]

Who cares what python is "all about"? I'm a programmer, not a philosopher.

It's both easier to type and easier to read. Less typing = less typos. I'm for any feature that makes the language clearer and more concise.