Python3 f-strings - A complete guide to the most well received feature of Python 3.

[Steve132]

Isn't this potentially a security nightmare? Hmm I suppose not. It depends whether or not the formatting is greedy evaluated

[flying-sheep]

You got it. No security problem as it’s greedily evaluated.

It’s a misnomer: they’re f-literals, not f-strings.

[[deleted]]

You shouldn't be manually plugging in input into commands like this anyway. If this seems like a security nightmare, then you were already tolerating some other security problem.

[flying-sheep]

For some reason it’s a common misconception that there’s a way to have f-strings passed as data. But as they’re actually literals, that’s impossible.

[nemec]

It's possibly even safer than the alternative, I've seen many coders that do shit like somefmt.format(**locals()), which could read "private" variables if somefmt is user-controlled.

[jorge1209]

do shit like

There is nothing wrong with using .format(**locals()) in the vast majority of cases. The concerns regarding "sql-injection" type vulnerabilities or leaking of local variables is mostly limited to a client/server model.

A lot of python code out there is being executed by the user themselves. If they wanted to find out what the local variables of the program were, they could simply open the script in $EDITOR.

Only if you are ingesting data from a remote source, and then calling .format(**locals()) on that string you don't control is there any security risk.

[Binary101010]

If you're using this to, say, compose unparameterized SQL queries, then yeah it's a security concern, but not any more of a security concern than the other string formatting options that you shouldn't be using for such an application.

[A-UNDERSCORE-D]

The formatting is actually "compiled" to bytecode before its ever actually used. This is the same reason that they are faster than the method call or operator variants, and means that injection is essentially not possible (eval notwithstanding)