3 ms·

How would this be different from a function sql() that operates on one of these new t-strings? The syntactic sugar of changing it from sql(t"...") doesn't seem

How would this be different from a function sql() that operates on one of these new t-strings? The syntactic sugar of changing it from sql(t"...") doesn't seem particularly valuable. The novel thing about t-strings is that they change the parsing at compile-time.

stavros 1y ago
It wouldn't be different, but it would be more convenient because we no longer have to count the number of %s, you'd put the variable inline.
- masklinn 1y ago
  That's... already the case of t-strings?
  - stavros 1y ago
    Yes, that's my point. The GP was already talking about a t-string.
    - masklinn 1y ago
      dmurray was comparing a hypothetical sql"..." with sql(t"..."). There are no %s either way.
Timwi 1y ago
> The syntactic sugar of changing it from sql(t"...") doesn't seem particularly valuable. It's valuable because: - IDEs could then syntax-highlight SQL inside of SQL strings and HTML inside of HTML strings - You can't accidentally pass an HTML string to your SQL library
wodenokoto 1y ago
It’s different from a function the same way f”” is different from f(“”) and t”” is different from t(“”) There’s nothing stopping you from building a Python function that parses a string looking for {} and then searching globals for those variables. And you can extend that to also do some code execution and formatting. To me the real sugar of f-strings is that the editor knows that it’s a template and not just a string. Expanding this to having SQL and regex syntax highlighting, linting and code formatting inside my Python code is a pretty cool prospect.