Hacker News Reader

Comment by pinoy420 | Hacker News Reader

Now instead of being explicit all it takes is someone unfamiliar with t strings (which will be almost everyone - still few know about f strings and their formatting capabilities) to use an f instead and you are in for a bad time.

View on HN

Any sane library will just error when you pass a string to a function that expects a template though. And that library will have types too so your IDE tells you before you get that far.

Such library functions tend to also accept a string as a valid input. E.g. db.execute from the GP usually works with strings to allow non-parametrized SQL queries.

The library should just refuse strings. If a non parametrized query is desired, it could require the user to supply a t-string with no {}.

> Such library functions tend to also accept a string as a valid input.

Also? They tend only to accept a string (possibly with some additional arguments, if there is an in-library way to handle parameterization) as input, because Template literally hasn't been an option. New APIs designed with Template available will look different.

This would break backwardcompatibility pretty hard. In many cases it may not be worth it.

But now at least the language has the necessary rope (and an opportunity for a cultural push to insist on it.)

Javascript already has prior art here.

A library can extend an existing database library like 'pg' so that PgClient#query() and PgPool#query() require string template statements.

That way 'pg' can continue working with strings, and people who want nice templated strings can use the small extension library, and the small extension library makes it impossible to accidentally pass strings into the query functions.

That is an issue, but essentially it boils down to the existing risk of unknowledgeable people not escaping untrusted inputs. The solution should be more education and better tooling (linters, SAST), and t-strings are likely to help with both.

t-strings allow building APIs which don't accept strings at all (or require some sort of opt-in), and will always error on such. That's the boon.

Having to write

    cr.execute(t"...")

even when there's nothing to format in is not a big imposition.

I suppose lack of overlap in the "interface surface" (attributes, including callables) between `str` and `Template` should nip the kind of issue in the bud -- being passed a `Template` and needing to actually "instantiate" it -- accessing `strings` and `values` attributes on the passed object, will likely fail at runtime when attempted on a string someone passed instead (e.g. confusing a `t`-string with an `f`-string)?

No, because they don't return a string, so good library authors will raise a type error when that happens, for exactly this reason.

Reply on news.ycombinator.com