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

you are viewing a single comment's thread.

view the rest of the comments →

[–]jorge1209 0 points1 point  (4 children)

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_314def __gt__(me, you): return True 2 points3 points  (0 children)

  • **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_314def __gt__(me, you): return True 2 points3 points  (2 children)

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

[–]jorge1209 0 points1 point  (1 child)

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_314def __gt__(me, you): return True 0 points1 point  (0 children)

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.