5 ms·

Excellent idea, I don't get the criticism, If a syntax such as f"{variable}" is already a feature - and turned out to be a popular one - why shouldn't we be ab

Excellent idea, I don't get the criticism, 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!

RhysU 2y ago
f("Consider...") 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.
- DataDive 2y ago
  Your reply appears to indicate that you do not properly understand the new proposed feature. It is most certainly not just about dropping two parentheses. > 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.
  - pauleveritt 2y ago
    (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
  - deleted 2y ago
    [deleted]

RhysU 2y ago

f("Consider...") 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.

DataDive 2y ago
Your reply appears to indicate that you do not properly understand the new proposed feature. It is most certainly not just about dropping two parentheses. > 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.
- pauleveritt 2y ago
  (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
- deleted 2y ago
  [deleted]