If a syntax such as f"{variable}" is already a feature - and turned out to be a popular one - why shouldn't we be able to add our own custom "f"s? Because that is what this is about. It might make generating output even simpler.
I applaud the idea and am pleased to see that Python keeps innovating!
greet("Hello {name}")
What was wrong with the standard way to write function application?
Python is sufficiently dynamic that an implementation of greet(...) can look up one level to resolve {name}, right? That's why Python will forever run like a dog. Might as take advantage of it to build such capabilities in user space.
This crap is going to end up inside f-strings inside tag-strings inside f-strings inside... We have a language. Don't extend it to express what it's perfectly capable of expressing already.
> Tag strings extract more than just a callable from the Interpolation. They also provide Python string formatting info, as well as the original text.
The feature is akin to moving print from a keyword to a function. That change also made a huge difference in that it unified the output stream and avoided having undefined objects like a "print" keyword.
Here, you can think of the feature as moving an "f" string from a hardcoded, predetermined definition to a generalizable and programmable behavior.
If "f" strings have become so popular so quickly it means they addressed a pressing need. It is logical to assume that a programmable version of an "f" string would be even more useful.
From their POV, inside the quotes, what you know about f-strings, you know here as well.
> ...other stuff that happens before evaluation...
A greet(string) function could parse the string and resolve the names itself:
parsed = parser(string)
resolved = resolver(parsed)
return formatter(resolved)
If you hate boilerplate, make the first two steps into a decorator.
A PEP introducing a grand unified theory of magic (tag strings) isn't inherently better than the status quo of some (f-string) magic. Less magic is better.
If the string is not an f-string, you get no help from Python tooling.
In both cases, you have to use frame hacks to get back to the scope, which has negative consequences.
So? It's been evaluated successfully. What more is there to do?
> If the string is not an f-string, you get no help from Python tooling.
Expose that tooling via the standard library. It's just pure functions.
> In both cases, you have to use frame hacks to get back to the scope, which has negative consequences.
What consequences? Isn't CPython forced to do all the nasty stuff anyhow when it's a language feature?