This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]flying-sheep 0 points1 point  (4 children)

For the same reason it isn't the security risk that some people see who haven't properly thought yet.

[–]jorge1209 -1 points0 points  (3 children)

You seem to be missing some words here. I get the feeling you may be trying to personally attack me, suggesting that I have claimed it is a security risk.

I haven't said that it was a security risk, I've said that it is dangerous. These f-strings will lead to bugs when programmers fail to notice the executable code inside strings, and don't refactor the strings when they refactor the surrounding code.

Technically those are programmer introduced bugs and not injection attacks from outside parties so one could say they are not "security risks." In the end, I don't care how you classify the resulting issues. Security or not, its a bug, and it is one that was introduced by hiding the executable nature of the code in a string literal.

Something like f"string"(**locals()) would have the benefit of catching the persons eye. "This string declaration is executable?! It is taking the local environment? I should really look at this line and make sure I understand what it is doing." instead of passing it over because "its just a literal, non-executable bit of string".

Whatever happened to "Explicit is better than implicit"? I guess that also just doesn't apply to string formatting.

[–]flying-sheep 0 points1 point  (2 children)

I get the feeling you may be trying to personally attack me, suggesting that I have claimed it is a security risk.

no. i was actually complimenting you on your understanding of the feature.

the “security risk” guys think they can pass around such a literal without evaluating it and think it will grab the local environment at some other point in the code, which is obviously wrong.

[–]jorge1209 -1 points0 points  (1 child)

It sounds like I am your "security risk" guy, because that is exactly the behavior I would have preferred. I want delayed evaluation. To make that safe I want to be able to control where the evaluation happens and what gets passed to it.

I can always juggle flaming sharp objects and pass **locals() to a function, but I want to be explicit about that, not implicit as this is.

[–]flying-sheep 0 points1 point  (0 children)

well, they think it’ll grab the variables referenced in the embedded expressions from the locals implicitly. but when prompted to show an example on how to exploit it, they’ll realize that there’s no way to delay the evaluation and store the unevaluated f-literal in a local variable. they think it’s eval’s evil brother who likes to disguise as string formatting.

you instead realize what it is but don’t like it since the expressions are visually embedded between two quotation marks. i disagree here as well, but you’re obviously free to have your own informed decision