4 ms·

Building off this question, it's not clear to me why Python should have both t-strings and f-strings. The difference between the two seems like a stumbling blo

Building off this question, it's not clear to me why Python should have both t-strings and f-strings. The difference between the two seems like a stumbling block to new programmers, and my "ideal python" would have only one of these mechanisms.

davepeck 2y ago
For one thing, `f"something"` is of type `str`; `t"something"` is of type `string.templatelib.Template`. With t-strings, your code can know which parts of the string were dynamically substituted and which were not.
- deleted 2y ago
  [deleted]
- all2 2y ago
  The types aren't so important. __call__ or reference returns type string, an f and a t will be interchangeable from the consumer side. Example, if you can go through (I'm not sure you can) and trivially replace all your fs with ts, and then have some minor fixups where the final product is used, I don't think a migration from one to the other would be terribly painful. Time-consuming, yes.
  - itishappy 2y ago
    Not sure that's true. `Template`s don't provide a `__str__` function, so you need to pass them to a processing function to get a `str` back. https://peps.python.org/pep-0750/#no-template-str-implementation https://peps.python.org/pep-0750/#no-template-str-implementa...
nhumrich 2y ago
f-strings immediately become a string, and are "invisible" to the runtime from a normal string. t-strings introduce an object so that libraries can do custom logic/formatting on the template strings, such as decided _how_ to format the string. My main motivation as an author of 501 was to ensure user input is properly escaped when inserting into sql, which you cant enforce with f-strings.
- williamdclt 2y ago
  > ensure user input is properly escaped when inserting into sql I used to wish for that and got it in JS with template strings and libs around it. For what it’s worth (you got a whole PEP done, you have more credibility than I do) I ended up changing my mind, I think it’s a mistake. It’s _nice_ from a syntax perspective. But it obscures the reality of sql query/parameter segregation, it builds an abstraction on top of sql that’s leaky and doesn’t even look like an abstraction. And more importantly, it looks _way too close_ to the wrong thing. If the difference between the safe way to do sql and the unsafe way is one character and a non-trivial understanding of string formatting in python… bad things will happen. In a one-person project it’s manageable, in a bigger one where people have different experiences and seniority it will go wrong. It’s certainly cute. I don’t thing it’s a good thing for sql queries.
  - nine_k 2y ago
    I understand your concern, and I think the PEP addresses it. Quite bluntly, t"foo" is not a string, while f"foo" is. You'll get a typecheck error if you run a typechecker like any reasonable developer, and will get a runtime error if you ignore the type mismatch, because t"foo" even lacks a __str__() method. One statement the PEP could put front and center in the abstract could be "t-strings are not strings".
    - guelo 2y ago
      > "t-strings are not strings" t-string is an unfortunate name for something that is not a string.
      - nine_k 2y ago
        I wish it were called "string templates" instead, with t"whatever" form being called a "template literal".
    - DonHopkins 2y ago
      Simpson's Individual Stringettes! https://www.youtube.com/watch?v=7qNj-QFZbew https://www.youtube.com/watch?v=7qNj-QFZbew
skeledrew 2y ago
Give it a few years to when f-string usage has worn off to the point that a decision can be made to remove it without breaking a significant number of projects in the wild.
- milesrout 2y ago
  That will never happen.
  - skeledrew 2y ago
    Well if it continues to be popular then that is all good. Just keep it. What matters is that usage isn't complex for anyone.
    - macNchz 2y ago
      Well now we'll have four different ways to format strings, since removing old ones is something that doesn't actually happen: "foo %s" % "bar" "foo {}".format("bar") bar = "bar"; f"foo {bar}" bar = "bar"; t"foo {bar}" # has extra functionality!
      - darthrupert 2y ago
        Five, if you count the log module. I hope t-strings will come there soon. log.error("foo happend %s", reason)
      - amenghra 2y ago
        This is where an opinionated linter comes in handy. Ensures people gradually move to the “better” version while not breaking backwards compatibility. It does suck for beginners who end up having to know about all variations until their usage drops off.
        QuercusMax 2y ago
        The linter is a big deal, actually. I've worked with Python off and on during the past few decades; I just recently moved onto a project that uses Python with a bunch of linters and autoformatters enabled. I was used to writing my strings ('foo %s % bar), and the precommit linter told me to write f'foo %{bar}'. Easy enough!

davepeck 2y ago

For one thing, `f"something"` is of type `str`; `t"something"` is of type `string.templatelib.Template`. With t-strings, your code can know which parts of the string were dynamically substituted and which were not.

deleted 2y ago
[deleted]
all2 2y ago
The types aren't so important. __call__ or reference returns type string, an f and a t will be interchangeable from the consumer side. Example, if you can go through (I'm not sure you can) and trivially replace all your fs with ts, and then have some minor fixups where the final product is used, I don't think a migration from one to the other would be terribly painful. Time-consuming, yes.
- itishappy 2y ago
  Not sure that's true. `Template`s don't provide a `__str__` function, so you need to pass them to a processing function to get a `str` back. https://peps.python.org/pep-0750/#no-template-str-implementation https://peps.python.org/pep-0750/#no-template-str-implementa...

nhumrich 2y ago

f-strings immediately become a string, and are "invisible" to the runtime from a normal string. t-strings introduce an object so that libraries can do custom logic/formatting on the template strings, such as decided _how_ to format the string. My main motivation as an author of 501 was to ensure user input is properly escaped when inserting into sql, which you cant enforce with f-strings.

williamdclt 2y ago
> ensure user input is properly escaped when inserting into sql I used to wish for that and got it in JS with template strings and libs around it. For what it’s worth (you got a whole PEP done, you have more credibility than I do) I ended up changing my mind, I think it’s a mistake. It’s _nice_ from a syntax perspective. But it obscures the reality of sql query/parameter segregation, it builds an abstraction on top of sql that’s leaky and doesn’t even look like an abstraction. And more importantly, it looks _way too close_ to the wrong thing. If the difference between the safe way to do sql and the unsafe way is one character and a non-trivial understanding of string formatting in python… bad things will happen. In a one-person project it’s manageable, in a bigger one where people have different experiences and seniority it will go wrong. It’s certainly cute. I don’t thing it’s a good thing for sql queries.
- nine_k 2y ago
  I understand your concern, and I think the PEP addresses it. Quite bluntly, t"foo" is not a string, while f"foo" is. You'll get a typecheck error if you run a typechecker like any reasonable developer, and will get a runtime error if you ignore the type mismatch, because t"foo" even lacks a __str__() method. One statement the PEP could put front and center in the abstract could be "t-strings are not strings".
  - guelo 2y ago
    > "t-strings are not strings" t-string is an unfortunate name for something that is not a string.
    - nine_k 2y ago
      I wish it were called "string templates" instead, with t"whatever" form being called a "template literal".
  - DonHopkins 2y ago
    Simpson's Individual Stringettes! https://www.youtube.com/watch?v=7qNj-QFZbew https://www.youtube.com/watch?v=7qNj-QFZbew

skeledrew 2y ago

Give it a few years to when f-string usage has worn off to the point that a decision can be made to remove it without breaking a significant number of projects in the wild.

milesrout 2y ago
That will never happen.
- skeledrew 2y ago
  Well if it continues to be popular then that is all good. Just keep it. What matters is that usage isn't complex for anyone.
  - macNchz 2y ago
    Well now we'll have four different ways to format strings, since removing old ones is something that doesn't actually happen: "foo %s" % "bar" "foo {}".format("bar") bar = "bar"; f"foo {bar}" bar = "bar"; t"foo {bar}" # has extra functionality!
    - darthrupert 2y ago
      Five, if you count the log module. I hope t-strings will come there soon. log.error("foo happend %s", reason)
    - amenghra 2y ago
      This is where an opinionated linter comes in handy. Ensures people gradually move to the “better” version while not breaking backwards compatibility. It does suck for beginners who end up having to know about all variations until their usage drops off.
      - QuercusMax 2y ago
        The linter is a big deal, actually. I've worked with Python off and on during the past few decades; I just recently moved onto a project that uses Python with a bunch of linters and autoformatters enabled. I was used to writing my strings ('foo %s % bar), and the precommit linter told me to write f'foo %{bar}'. Easy enough!