A format function that arbitrarily executes code from within a format string sounds like a complete nightmare. Log4j as an example.
The rejection's example shows how that arbitrary code within the string could instead be fixed functions outside of a string. Safer, easier for compilers and programmers; unless an 'eval' for strings is what was desired. (Offhand I've only seen eval in /scripted/ languages; go makes binaries.)
An f/t string is syntax not runtime.
Instead of
"Hello " + subject + "!"
f"Hello {subject}!"
And instead of
query(["SELECT * FROM account WHERE id = ", " AND active"], [id])
query(t"SELECT * FROM account WHERE id = {id} AND active")
The Rejected Golang proposal cited by the post I'm replying to. NOT Python's present PEP or any other string that might resolve magic variables (just not literally eval / exec functions!).
However the difficulty of understanding also illustrates the increased maintenance burden and language complexity.
E.G. Adapting https://github.com/golang/go/issues/34174
f := 123.45
fmt.Fprintln("value=%08.3f{f}") // value=0123.450
fmt.Fprintln("value=%08.3f", f) // value=0123.450
s := "value"
fmt.Fprintln("value='%50s{s}'") // value='<45 spaces>value'
fmt.Fprintln("value='%50s'", s) // value='<45 spaces>value'
fmt.Fprintln("value=%08.3f%{f}") // value=0123.450
fmt.Fprintln("value='%50s%{s}'") // value='<45 spaces>value'The proposal was for the same.
You can verify that either via static typechecking, or at runtime.
When compiling, those can be lowered to simple string concatenation, just like any for loop can be lowered to and represented as a while.
It is NOT about the possibility of referencing existing / future (lazy / deferred evaluation) string literals from within the string, but about a format string that would literally evaluate arbitrary functions within a string.
On the other hand, the current solution offered by Go (fmt.Sprintf) is the one who supports a user-supplied format String. Admittedly, there is a limited amount of damage that could be done this well, but you can at the very least cause a program to panic.
The reason for declining this feature[1] has nothing to do with what you stated. Ian Lance Taylor simply said: "This doesn't seem to have a big advantage over calling fmt.Sprintf" and "You can a similar effect using fmt.Sprint". He conceded that there are performance advantages to string interpolation, but he doesn't believe there are any gains in usability over fmt.Sprintf/fmt.Sprint and as is usual with Go (compared to other languages), they're loathe to add new features to the compiler[2].
[1] https://github.com/golang/go/issues/34174#issuecomment-14509...
[2] https://github.com/golang/go/issues/34174#issuecomment-53013...
The t-string proposal involves using new data types to abstract the concatenation and formatting process, but it's still a compile-time process - and the parts between the braces still involve code that executes first - and there's still no separate type for the overall t-string literal, and no way to end up eval'ing code from user-supplied data except by explicitly requesting to do so.
Python source code is translated into bytecode for a VM just like in Java or C#, and by default it's cached in .pyc files. It's only different in that you can ask to execute a source code file and the compilation happens automatically before the bytecode-interpretation.
`SyntaxError` is fundamentally different from other exceptions because it can occur during compilation, and only occurs at run-time if explicitly raised (or via explicit invocation of another code compilation, such as with `exec`/`eval`, or importing a module). This is also why you can't catch a `SyntaxError` caused by the invalid syntax of your own code, but only from such an explicit `raise` or a request to compile a source code string (see https://stackoverflow.com/questions/1856408 ).
So, a template? I certainly ain't gonna be using go for its mustache support.
any_func(f"{attacker_provided}") <=> eval(attacker_provided), from a security/correctness perspective