PEP 750 – Template Strings (t-strings) have been accepted

Re:PEP 750 – Template Strings (t-strings) have been accepted by mjevans on Thursday April 10, 2025 @10:05PM (#43649790)

My reply was to the parent post's SPECIFIC example of Golang's rejected feature request. Please go read that proposal.

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.

[ Parent | on HN ]

Re:PEP 750 – Template Strings (t-strings) have been accepted by unscaled on Thursday April 10, 2025 @10:25PM (#43649918)

The proposal doesn't say anything about executing code in user-supplied strings. It only talks about a string literal that is processed by the compiler (at which point no user-supplied string can be available).

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

[ Parent | on HN ]