-_- [LWN.net]

-_-

Posted Jan 24, 2025 7:45 UTC (Fri) by LtWorf (subscriber, #124958)
Parent article: A revamped Python string-formatting proposal

What is the point for this when perfectly good templating libraries exist?

The batteries included thing no longer applies since python developers have decided this is no longer the case for python. So it looks to me as developers finding something to keep busy, rather than something users of the language actually need.

to post comments

It's actually one of the most powerful enhancements one can make to a programming language

Posted Jan 24, 2025 14:00 UTC (Fri) by rrolls (subscriber, #151126) [Link] (5 responses)

My reply to siddh above should explain this, since without being able to build interpolations natively within the syntax of a language (which is what t-strings will do for Python), any "perfectly good templating library" is ultimately just a particularly complex string formatting technique, so it'll fall foul of the same problems once your use case gets sufficiently complex itself.

t-strings is far more than "developers finding something to keep busy" - I would put it in the same category of powerful, fundamental enhancement as Ruby/PHP fibers (which are more powerful than Python's asyncio - I wish we had fibers in Python).

It's a shame that t-strings seem to be so easy to misunderstand as "just more syntactic sugar for str.format" because saying that that is selling them short is a severe understatement.

It's actually one of the most powerful enhancements one can make to a programming language

Posted Jan 26, 2025 23:59 UTC (Sun) by marcH (subscriber, #57642) [Link] (4 responses)

> It's a shame that t-strings seem to be so easy to misunderstand as "just more syntactic sugar for str.format" because saying that that is selling them short is a severe understatement.

In these situations there is really only one way: finding good _demoes_ as you just did above. They have to be short and simple enough to be in reach of "casual" readers with limited time, while being complex enough to demonstrate real value. It can be pretty hard and also very dependent on the new feature itself.

From https://lwn.net/Articles/1005903/ above
> There is a wealth of experience now on SQL injections, JS injections, and the like, ...
> But with a t-string, LibFoo knows exactly which parts were written by Alice and intended to be treated as syntax, and which parts were passed in via substitutions.

This looks pretty much like SQL's "PreparedStatements" which is the (universal?) cure for SQL injections. Are these new templates following the same logic? That is: _not_ "serializing"/flattening but preserving structure? In a more generic way and in a more generic language.

So, maybe rewriting this with t-strings would make a good demo?
https://en.wikipedia.org/wiki/Prepared_statement#Python_D...

Not because it would show anything significantly new, but because it would show how more generic t-strings are?

It's actually one of the most powerful enhancements one can make to a programming language

Posted Jan 28, 2025 17:46 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (3 responses)

Unfortunately, that Wikipedia example is probably not the easiest thing to translate into t-strings, because it uses executemany, and it is not immediately obvious how you would implement a t-string version of that.

Here is an exercise that might help illustrate the power of t-strings: Write an example of a "classic" SQL injection vulnerability, using f-strings for naive interpolation, and then change the f to a t. In principle, it is possible for an SQL library to turn the resulting t-string into an entirely safe prepared statement and execute it correctly (at least for the vast majority of real-world interpolations). However, this does require the library to support it, which is an issue. Another issue is that f-strings will serve as an attractive nuisance for less experienced developers, so it is likely wise to introduce a new method or function that *only* accepts t-strings, even for commands that have no interpolations (so that you can't pass it an f-string at all). You could then train developers to only use the new method/function for all SQL execution, and introduce a linter to find uses of the old method/function.

It's actually one of the most powerful enhancements one can make to a programming language

Posted Jan 28, 2025 22:32 UTC (Tue) by LtWorf (subscriber, #124958) [Link] (2 responses)

I don't think your example is great either. If you make a function that reject strings, then a "SELECT name FROM names;" will fail because it's a string. Remember that fstrings do not exist at runtime so you have no way of knowing if it's an fstring or just a regular string with no parameters.

It's actually one of the most powerful enhancements one can make to a programming language

Posted Jan 29, 2025 0:28 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (1 responses)

> I don't think your example is great either. If you make a function that reject strings, then a "SELECT name FROM names;" will fail because it's a string.

Yes, that is the intention.

> Remember that fstrings do not exist at runtime so you have no way of knowing if it's an fstring or just a regular string with no parameters.

And that is why it is the intention - because there is no other way to reject f-strings.

It's actually one of the most powerful enhancements one can make to a programming language

Posted Jan 29, 2025 0:28 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

(In case anyone didn't read the PEP: You can just prefix a literal string with no interpolations with t, and it still gives you a template and not a literal string.)