4 ms·

I never put an f in front of a string if I'm not putting variables within it. Linters will even complain if you have a f string without variables. I assume it

I never put an f in front of a string if I'm not putting variables within it. Linters will even complain if you have a f string without variables. I assume it will be the same for t strings.

davepeck 2y ago
For the reasons discussed above, I'm not sure that it will be the case for t-strings. I think it'll take a little while for frameworks/libraries to adapt (while still maintaining backward compatibility) and a while for best practices to find their way into our linting and other tools.
- 0cf8612b2e1e 2y ago
  If you can use a string anywhere you can use a t-string, then a non parametrized t-string is a code smell (lining error). If there is a dedicated template-string API, then there is the implicit threat you are breaking backwards compatibility to stop using regular strings.
  - davepeck 2y ago
    > If you can use a string anywhere you can use a t-string You can't; they're different types. t-strings are not `str` It's up to good framework/API design to take advantage of this.
    - WorldMaker 2y ago
      Yeah, "t-string" is possibly a misnomer, because they are in fact at runtime a Template object (from string.templatelib).
    - 0cf8612b2e1e 2y ago
      A library writer ultimately has to decide if they accept both types. For a database cursor, do you take regular strings + parameter arguments and template strings? Or dedicate a new API to the idea? cursor.execute(“select * from x where foo=?”, {foo=1}) # while also allowing cursor.execute(t“select * from x where foo={foo}”) #Vs cursor.executetemplate(“select * from x where foo={foo}”) If ‘execute’ takes string and t-string, then I would consider it a problem to use a t-string without parameters. If there is a novel API just for t-strings, then you are implying widespread breaking changes as you have a schism between the two ways of providing parameters.
      - davepeck 2y ago
        My point was that library authors will need to consider this carefully. If you're writing a library where injection attacks matter, then -- long term -- you almost certainly do not want a single method that accepts `Union[str, Template]`. You probably either want to avoid accepting `str` entirely, or perhaps provide two separate methods. Some period of deprecation seems inevitable.
maleldil 2y ago
Linters complain because f"hello" and "hello" are the _exact_ same string. t"hello" isn't even a string.

I never put an f in front of a string if I'm not putting variables within it. Linters will even complain if you have a f string without variables. I assume it will be the same for t strings.

davepeck 2y ago

For the reasons discussed above, I'm not sure that it will be the case for t-strings. I think it'll take a little while for frameworks/libraries to adapt (while still maintaining backward compatibility) and a while for best practices to find their way into our linting and other tools.

0cf8612b2e1e 2y ago
If you can use a string anywhere you can use a t-string, then a non parametrized t-string is a code smell (lining error). If there is a dedicated template-string API, then there is the implicit threat you are breaking backwards compatibility to stop using regular strings.
- davepeck 2y ago
  > If you can use a string anywhere you can use a t-string You can't; they're different types. t-strings are not `str` It's up to good framework/API design to take advantage of this.
  - WorldMaker 2y ago
    Yeah, "t-string" is possibly a misnomer, because they are in fact at runtime a Template object (from string.templatelib).
  - 0cf8612b2e1e 2y ago
    A library writer ultimately has to decide if they accept both types. For a database cursor, do you take regular strings + parameter arguments and template strings? Or dedicate a new API to the idea? cursor.execute(“select * from x where foo=?”, {foo=1}) # while also allowing cursor.execute(t“select * from x where foo={foo}”) #Vs cursor.executetemplate(“select * from x where foo={foo}”) If ‘execute’ takes string and t-string, then I would consider it a problem to use a t-string without parameters. If there is a novel API just for t-strings, then you are implying widespread breaking changes as you have a schism between the two ways of providing parameters.
    - davepeck 2y ago
      My point was that library authors will need to consider this carefully. If you're writing a library where injection attacks matter, then -- long term -- you almost certainly do not want a single method that accepts `Union[str, Template]`. You probably either want to avoid accepting `str` entirely, or perhaps provide two separate methods. Some period of deprecation seems inevitable.

maleldil 2y ago

Linters complain because f"hello" and "hello" are the _exact_ same string. t"hello" isn't even a string.