2 ms·

(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-st

(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 2y ago
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 2y ago
  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 2y ago
    > 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 2y ago
      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 https://github.com/jviide/htm.py/issues/11

RhysU 2y ago

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 2y ago
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 2y ago
  > 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 2y ago
    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 https://github.com/jviide/htm.py/issues/11