I see your point, but the syntax inside of fstrings forms an entirely new sub-language (DSL). I can look at old python and know exactly how the .format() calls parse with positional and named keyword arguments, but looking at the fstrings I need to be familiar with all of the new magic.
I've heard similar complaints about the loop macro in Common Lisp, and this feels a bit like shell or Tcl strings which could mean anything (arguments to sed/awk or paths to widgets/urls). However, I guess people are familiar with regular expressions as a completely foreign nested language (DSL), so this isn't much different than that.
I disagree, especially when using named parameters. The new style is too implicit.
Re:Things to use in Python 3
by hannasanarion on Wednesday May 15, 2019 @08:09AM
(#19918581)
How is it implicit? Every insertion is expressed in exactly the place where it will print. It's way more explicit than having a placeholder and a value on completely different parts of the expression.
> It's way more explicit than having a placeholder and a value on completely different parts of the expression.
No its not.
"My name is {}, I'm {}'{}'' tall and live in {}".format(name, location, feet, inches)
f"My name is {name}, I'm {location}'{feet}'' tall and live in {inches}."I did mention named parameters, you are using positional parameters to make your point. You don't even list the variables in your example. That seems pretty implicit to me.
I think this is more explicit:
"My name is {name}, I'm {feet} tall and live in {location}.".format(name="Bob", location="USA", feet=7)
Re:Things to use in Python 3
by isaacremuant on Wednesday May 15, 2019 @09:58AM
(#19919410)
Your example is not representative because you're using literals.
Your actual example would be:
"My name is {name}, I'm {feet} tall and live in {location}.".format(name=name, location=location, feet=feet)
f"My name is {name}, I'm {feet} tall and live in {location}."
The literals were just an example. And personally I find it more explicit, which is my original point.
If its faster to run, then fair enough.
Using your example, I think
"My name is {name}, I'm {feet} tall and live in {location}.".format(name="Bob", location="USA", feet=7)
is less explicit than
"My name is Bob, I'm 7 feet tall and live in USA."
and that last one is faster to run ;-)
So, thanks to f"", no need for what I find to be an ugly additional call to .format(...), that is just visual clutter for most cases.
The only reasons I could see for a call with a dedicated dict is data exfiltration from a user provided format string executed on python code they do not control, or renaming/subsetting of keywords for cleanliness. Both are special cases, and that's the effect the current implementation has, thankfully.