6 ms·

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 format

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.

falcor84 1y ago
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.
- masklinn 1y ago
  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.
deleted 1y ago
[deleted]
mcintyre1994 1y ago
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.
- Dx5IQ 1y ago
  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.
  - kccqzy 1y ago
    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 {}.
  - dragonwriter 1y ago
    > 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.
- _Algernon_ 1y ago
  This would break backwardcompatibility pretty hard. In many cases it may not be worth it.
  - eichin 1y ago
    But now at least the language has the necessary rope (and an opportunity for a cultural push to insist on it.)
  - hombre_fatal 1y ago
    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.
sanderjd 1y ago
No, because they don't return a string, so good library authors will raise a type error when that happens, for exactly this reason.
hackrmn 1y ago
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)?

falcor84 1y ago

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.

masklinn 1y ago
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.

deleted 1y ago

[deleted]

mcintyre1994 1y ago

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.

Dx5IQ 1y ago
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.
- kccqzy 1y ago
  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 {}.
- dragonwriter 1y ago
  > 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.
_Algernon_ 1y ago
This would break backwardcompatibility pretty hard. In many cases it may not be worth it.
- eichin 1y ago
  But now at least the language has the necessary rope (and an opportunity for a cultural push to insist on it.)
- hombre_fatal 1y ago
  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.

sanderjd 1y ago

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

hackrmn 1y ago

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)?