16 ms·

Feels unnecessary... Can't think of a good reason now on why I would need this rather than just a simple f-string. Any unsafe string input should normally be

by _el1s7 2y ago

Feels unnecessary... Can't think of a good reason now on why I would need this rather than just a simple f-string. Any unsafe string input should normally be sanitized before being added in a template/concatenation, leaving the sanitization in the end doesn't seem like the best approach, but ok.

stavros 2y ago
Yeah, I generally like most of the stuff that goes into Python, but I have to admit I can't really see the usefulness in this (or, at least, enough usefulness to warrant making it standard). One of the PEP's developers, Lysandros, presented this in our local meetup, so I am passingly familiar with it, but still, I might be missing something. I guess the crux of it is that I don't understand why it's `t"some string"` instead of `Template("some string")`. What do we gain by the shorthand?
- _el1s7 2y ago
  I guess this could be useful in SQL for escaping values, I saw a project on the comments here. With templates: mysql.execute(t"DELETE FROM table WHERE id={id} AND param1={param1}") Without templates: mysql.execute("DELETE FROM table WHERE id=%s AND param1=%s", [id, param1]) So one less argument to pass if we use templates. But yeah it does seem a bit confusing, and maybe kinda not pythonic? Not sure.
  - zahlman 2y ago
    SQL templating is one of the explicitly cited motivating use cases.
- zahlman 2y ago
  > What do we gain by the shorthand? Because it's new syntax, it allows for parsing the literal ahead of time and eagerly evaluating the substitutions. Code like bar = 42 spam = t"foo {bar*bar} baz" essentially gets translated into bar = 42 spam = Template("foo ", Interpolation(bar*bar), " baz") That is: subsequent changes to `bar` won't affect the result of evaluating the template, but that evaluation can still apply custom rules.
  - stavros 2y ago
    Ah OK, I see what you mean, so they're basically an f-string that hasn't been "baked in" yet, and you can still access all its parameters. That's pretty cool.
    - zahlman 2y ago
      Yes, that's also a fine way to describe it IMO.

by _el1s7 2y ago

stavros 2y ago

Yeah, I generally like most of the stuff that goes into Python, but I have to admit I can't really see the usefulness in this (or, at least, enough usefulness to warrant making it standard). One of the PEP's developers, Lysandros, presented this in our local meetup, so I am passingly familiar with it, but still, I might be missing something. I guess the crux of it is that I don't understand why it's `t"some string"` instead of `Template("some string")`. What do we gain by the shorthand?

_el1s7 2y ago
I guess this could be useful in SQL for escaping values, I saw a project on the comments here. With templates: mysql.execute(t"DELETE FROM table WHERE id={id} AND param1={param1}") Without templates: mysql.execute("DELETE FROM table WHERE id=%s AND param1=%s", [id, param1]) So one less argument to pass if we use templates. But yeah it does seem a bit confusing, and maybe kinda not pythonic? Not sure.
- zahlman 2y ago
  SQL templating is one of the explicitly cited motivating use cases.
zahlman 2y ago
> What do we gain by the shorthand? Because it's new syntax, it allows for parsing the literal ahead of time and eagerly evaluating the substitutions. Code like bar = 42 spam = t"foo {bar*bar} baz" essentially gets translated into bar = 42 spam = Template("foo ", Interpolation(bar*bar), " baz") That is: subsequent changes to `bar` won't affect the result of evaluating the template, but that evaluation can still apply custom rules.
- stavros 2y ago
  Ah OK, I see what you mean, so they're basically an f-string that hasn't been "baked in" yet, and you can still access all its parameters. That's pretty cool.
  - zahlman 2y ago
    Yes, that's also a fine way to describe it IMO.