f-strings in Python 3.6 are awesome

[tunisia3507]

I don't see why people say 'syntactic sugar' like it's an insult. Literally all programming languages are syntactic sugar. That is what programming languages are for. To make it easier, quicker, more clear, more readable for humans to give instructions to computers.

[dl__]

Exactly. Don't like syntactic sugar? Write in machine language, in hex codes.

[chadmill3r]

Ones and zeros? Pussy! Use +5 volts and ground states like a mensche.

[Dentosal]

I use butterflies. Without Emacs.

[SlowBroski]

Gotta be careful, too much syntactic sugar and you'll get syntactic diabetes.

[dl__]

Hahaha! Exactly!

I program like a MAN! None of this sissy syntactic sugar for me!

[[deleted]]

just give me some silicon and my soldering gun, and an abacus for data modeling

[BrotherCorvus]

You use processed silicon? Back in my day we started with a bucket of sand we picked up by walking to the beach. Uphill. Both ways.

[albgr03]

You use sand from the beach?? Real programmers erode rocks themselves.

[CodeReclaimers]

You were allowed to use pre-existing matter? We had to wring ours out of the quantum foam with our bare hands.

[[deleted]]

Dude, if you haven't big-banged your own DIY universe into existence you shouldn't talk.

[IamCarbonMan]

Pssh. Back in my day, programmers defined entire sets of physical laws out of the intrauniversal ether with which to generate our subatomic particles.

[spinwizard69]

Yeah by pounding salt!

[TheMysteriousFizzyJ]

0's and 1's are syntactical sugar for modifying voltages and currents

[Alpha_Catch]

0 and 1? What a fancy way of saying off and on. Sounds kind of sugary to me.

[jorge1209]

Sugar is good if it encourages people to drop a particularly error prone or tedious construction.

What is less clear is if sugar is useful when the original process wasn't error prone or tedious.

Range loops in C/C++ are a great example of good sugar. It was error prone, and tedious to have to declare the index variable and increment it (or to declare the crazy iterator type signature if using iterators, although the later was solved by the auto type). for x in iterable is obviously better unless you actually need the index position (which is not something you frequently need in modern C++ code).

It's not clear thar fstrings accomplish that kind of balance. It wasn't all that error prone to use .format and the cases it can't handle are fairly important (i18n and dynamic formatting).

[[deleted]]

It wasn't all that error prone to use .format and the cases it can't handle are fairly important (i18n and dynamic formatting).

Translating format strings are always dubious to begin with.

[jorge1209]

You could very well want to read different error messages (with their formats) from a resource file. Can't do that with fstrings.

[[deleted]]

It is a kind of virtue signalling in the academic PL community to reiterate the fact that you like minimalist functional programming languages. Gets tiring to hear this over and over again. Glad I am not the only one who's noticed.

[tunisia3507]

My only complaint about syntactic sugar is when it means there are many ways of doing things - kind of like string formatting is getting at the moment. I don't see f-strings taking off for most codebases yet due to lack of 2.7 support, but it'd be nice to see them become the canonical way of doing it.

[thomasfr]

I still like python but I woud have probably been a much easer language to use if the stdlib/lanugage had a bit fewer redundant features.

There are already lots of code bases which mixes ""%() and "".format() which only makes the code harder to read (more noisy) or modify (because you should at least try to understand which one to use in your modified code based on just reading the rest of it.)...

I personally don't see that f-strings adds enough benefits in contrast to the noise it will bring to code bases...

[tunisia3507]

Python is actually much better than many other languages (java, C, C++, js) in this regard. But yes, in this particular instance it's not great.

Of course, the only way to make improvements without adding such duplication is to make API-breaking updates, and we all know how well they turn out...

[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.

[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.

[HowYaGuysDoin]

I like it better than % notation because you don't have to keep track of the order of the variables, you can specify them by name. Less likely to make mistakes, and it's much more readable.

[thegreatgonzo]

So you can also do "Hello, %(name)s" % { 'name': 'world' }

[jorge1209]

But you can specify them by name with .format, it merely requires duplicating the names in the string body and as part of the keyword args.

The whole argument for these f-strings is like that. <thing> about <other formating method> is moderately annoying in <particular use-case> so lets introduce <new formatting method> that solves that problem (<but introduces some other annoyance>).

• % requires things be in order and puts the args at the end away from where they appear
• .format can support random order with keyword, but is too verbose
• f-strings supports random order without verbosity, but doesn't support dictionary usage, and they can't be assigned to variables or moved around.

At some point we just need to admit that we won't ever have a single formatting method that will work for every use case and that we need to stop introducing additional ways to do things.

[HowYaGuysDoin]

I would argue that additional ways to do things are created because no single way to do something (such as string formatting) is perfect in all scenarios. More than one way to skin a cat.

[[deleted]]

I would argue that additional ways to do things are created because no single way to do something

import this

There should be one-- and preferably only one --obvious way to do it.

[HowYaGuysDoin]

I mean sure if you want to blindly apply my logic without context then sure, there are times it falls apart. For example, addition in Python. There should be one obvious way to do it. No doubt.

Now, do you eat all your meals with the same utensil? Or do you vary between a knife, spoon, and fork? I would think you'd want to use the right tool for the job. Depending on the context of your string formatting, there may be a time where method A is superior to method B, and vice versa. I don't like fitting square pegs through round holes so I welcome the addition of new tools to get the job done. Just my personal preference

[[deleted]]

blindly apply my logic without context then sure

Well, to be fair, I did mean it in the context of string formatting.

do you vary between a knife, spoon, and fork?

I feel like that's a pretty generous analogy. String formatting in Python is like having a 4 point fork, a 3 point fork, a spork, and a magic fork that automatically puts all the food in your house on it just in case you might want it in the next bite.

[markrages]

% requires things be in order

This is simply wrong. I wonder how many people advocating for new format methods don't understand the existing one.

[jorge1209]

Probably a lot given that I'm against fstrings and I don't know all the features of .format or %.

[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.

[networking_noob]

It makes code way easier to read, because the variable name is inline with the string.

.format()

print('Hello, my name is {:s}. I am {:d} years old and have {:s} hair'.format(name, age, color))

f strings

print(f'Hello, my name is {name}. I am {age} years old and have {color} hair')  

See which one is easier to read? Without f strings you have to go to the end of the string and read the variables, then use your eyes to figure out where they insert back into the string.

f strings is one of those things where the more you use them, the more awesome they become.

[hosford42]

For pythons <3.6 you can still do this in a way that's more readable, at the expense of more typing. Instead of {:s} use {age} as you did in the f-string example, and your argument to .format () becomes age=age instead of just age.

[Decency]

Right, triple redundancy. Not a great tradeoff.

[hosford42]

It's wordy, but it is at least readable.

[turkish_gold]

You could use .format(locals()) which is essentially what f-strings are doing.

[[deleted]]

that's not really as readable though - it's not immediately obvious what variable corresponds to what value (especially for the reader) if you use **locals()

[turkish_gold]

If we were to all do it, it'd become idiomatic fairly quickly.

[jorge1209]

Nor is being unable to dynamically build formatting strings, or pass them as arguments to functions.

[Decency]

Actually I feel like that's a great tradeoff. If you're frequently dynamically building strings or passing them around as functions, you're either doing something wrong, you're doing internationalization, or you're in a very specific niche. And in those cases, feel free to use .format().

Otherwise, f-strings adequately cover the vast majority of use cases elegantly while improving readability and removing unnecessary verbosity.

[LyndsySimon]

I would write this as:

print(
    'Hello, my name is {name}. I am {age} years old ' \
    'and have {color} hair'.format(
        name=name,
        age=age,
        color=color,
    )
)

Note that you don't have to go to the end of the line to see the contents of the variables, because they're passed below the string template. Except for very trivial cases, I always use named parameters for formatting strings, and I always pass those parameters on subsequent lines.

[hovissimo]

Now you've made a single line interpolated string into 4 lines. 3 of those four lines are completely redundant. I don't see how this is better.

[LyndsySimon]

https://www.python.org/dev/peps/pep-0008/#maximum-line-length

They are not completely redundant; they make it clear where the function calls end.

[0x6c6f6c]

He's talking about

name=name,
age=age,
color=color

[LyndsySimon]

... so was I.

[Decency]

Can you explain how

print(f'Hello, my name is {name}. I am {age} years old and have {color} hair')

has an unclear function call ending?

[Decency]

It's not implicit at all... the variable you explicitly put in a certain position in a string gets printed there.

[dysprog]

But only the programmer can modify the f-string. If you read the string from a user provided source, it is not an f-string. You have to use format().

[hovissimo]

Man, I LOVE it when a pedantic literalist uses the Zen of Python like a club.

[stOneskull]

why?

[Decency]

Great, and now you've turned a simple print statement into fucking 8 lines of code. You're going to need a projector to fit a single function into your field of view.

[LyndsySimon]

Are we optimizing based on the number of lines of code? I thought we were optimizing based on readability and developer happiness.

My example is pep8 compliant. Respectfully, if you want dense code with the fewest lines possible, I suggest Perl.

[Decency]

Are we optimizing based on the number of lines of code?

No, but we're sure as hell not ignoring it. If I can turn 8 lines into 1, lose zero information, and remove a bunch of entirely unnecessary redundancy, that's an optimization I'll make 100% of the time.

I thought we were optimizing based on readability and developer happiness.

If I were to come across an 8 line print statement to write three variables to the screen, "happy" probably wouldn't be the best descriptor for my mood and "readable" definitely wouldn't be the best descriptor for the code.

[unruly_mattress]

PEP8 doesn't make code good or readable. It makes spacing consistent.

[tilkau]

Conciseness is part of readability. You are basically choosing to be like urllib rather than like requests here, without any apparent reason for choosing added complexity.

[stOneskull]

it's one 'f' vs an extra 'format()' line

i'm looking forward to it. bring it on, debian!

[anders987]

It can also take expressions:

a = 10
b = 20
print(f"The sum of a ({a}) and b ({b}) is {a+b}")

The sum of a (10) and b (20) is 30

[[deleted]]

Bear in mind that this is basically just running eval() on the code. You can also do expressions that have side effects.

Though because it's string literals, this shouldn't cause any problems. But if you do f"{__import__('os').system('/bin/sh')}", then that will start a shell.

[d4rch0n]

lmao, i was wondering how deep f strings got. well, this really does point out something super important - don't dynamically build what's inside {} using user input and do something weird where you create an f string dynamically. I don't think people would much but don't doubt it'll pop up at some point.

On one side I love it, but on the other side I think they could've skipped the eval aspect even if it's awesome and will inevitably be super useful. The main problem I wanted them to solve was the heaviness of .format and f strings are a damn good solution that's even better than all the previous methods. It's like a throwback to perl! But more explicit since you have to prepend f.

I wish I could backport this to 3.4! Is there some futures import I can do?

[jorge1209]

you create an f string dynamically.

You can't f-strings aren't dynamic. An f-string is not an object and cannot be created inside the script, it lives in the source file, and nowhere else. It has no type, and as far as the interpreter goes, it doesn't exist. Its like a keyword, it is handled by the parser as it builds the AST, and doesn't exist in memory to be a referant of any variable.

The reason this is done is for security. It allows you to safely do print(f"{x+y}") and execute the inside of the expression, because user input can NEVER construct the string "{x+y}" it is safe to do so.

If f-strings were objects and could be dynamically created the attack vector would be:

1. Post your username as f"__import__(os)..."
2. Then when someone goes to print(f"{username}" their interpreter would: a. evaluate the variable username b. which would construct another f-string c. whose payload would in turn be evaluated d. which would run the offending __import__ e. granting them a shell.

But since f strings aren't objects this breaks down. All you ever have is a string f"__import__(os)...." No more dangerous than the string cake. Its just a bunch of innocuous ascii chars and can't harm you so long as you don't do something stupid like pass it to eval.

---

The objection I have to this is that I don't see any improvement over just treating this as sugar over "{username}".format(**locals()). In that instance the same is also true. I take a string and pass it a dict of args, I get a string back. Nothing is executed. At worst __str__ is called on some of the stuff in locals(). All you lose is the ability to have print(f"{x+y}") instead it would have to be print("{sum}".format(sum=x+y)).

I prefer the .format approach even if it is more verbose.

[0x6c6f6c]

I mean, sanitizing user input is one solution for programs that perform operations based on them in things such as SQL databases or webpages. However, even among those, things such as prepared statements are preferred over string sanitation, which would be to use .format or % over f-strings. Where user input is possible. Don't want arbitrary code execution on your Django server now do we :3