[pauleveritt]

(PEP co-author here.) You've described it well. As the "How to teach it section" emphasizes, we'd like consumers of tag functions to just think of it as an f-string with other stuff that happens before evaluation.

From their POV, inside the quotes, what you know about f-strings, you know here as well.

[RhysU]

Why could you not know these things without a language feature?

> ...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.

[pauleveritt]

If the string is an f-string, it is immediately evaluated and you no longer have access to the interpolation info for a resolver.

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.

[RhysU]

> If the string is an f-string, it is immediately evaluated and you no longer have access to the interpolation info for a resolver.

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?

[jimbaker]

Frame hacks with sys._getframe necessarily imply dynamic scope not lexical scope. Dynamic scope does not work with nested functions, including comprehensions. See this issue with the htm library, https://github.com/jviide/htm.py/issues/11