3 ms·

Not sure about introducing yet another string prefix. Between f-strings, raw strings, and i18n stuff, it’s already getting crowded. Curious how readable this wi

Not sure about introducing yet another string prefix. Between f-strings, raw strings, and i18n stuff, it’s already getting crowded. Curious how readable this will be in large codebases.

wodenokoto 1y ago
I'm of the opposite opinion. Let's set the prefixes free! from sql import sql query = sql"SELECT user_id, user_name FROM {user_table_versioned} WHERE user_name = {user_name}"
- dmurray 1y ago
  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.
- mcintyre1994 1y ago
  This is how JavaScript does it with tagged template literals. Your sql there would just be a function that receives the array of strings/values and returns whatever.
- masklinn 1y ago
  This was considered and rejected: https://peps.python.org/pep-0750/#arbitrary-string-literal-prefixes https://peps.python.org/pep-0750/#arbitrary-string-literal-p...
- dsego 1y ago
  This is what JS does with tagged template literals. https://github.com/dsego/sql_tag https://github.com/dsego/sql_tag
mulmboy 1y ago
Are there string prefixes for i18n stuff?
- Biganon 1y ago
  They're probably talking about the convention of using _ as an alias for `translate`
albert_e 1y ago
"Yet another" is not my main worry The concept of prefixes itself feels a little deviant from readable code that is close to human language -- which is the spirit of Python
- Timwi 1y ago
  The single letter f or t does make it unnatural to read, but if it were sql"..." or html"...", I think that would help with that.
- matusp 1y ago
  Additionally, it will probably be confusing that it is called a t-string but it is actually a constructor for a Template object and not string at all. I would rather see a new special term `template` than this.
- toxik 1y ago
  Should have been a keyword. a = template "foo {bar}" As should raw and format.

Not sure about introducing yet another string prefix. Between f-strings, raw strings, and i18n stuff, it’s already getting crowded. Curious how readable this will be in large codebases.

wodenokoto 1y ago

I'm of the opposite opinion. Let's set the prefixes free! from sql import sql query = sql"SELECT user_id, user_name FROM {user_table_versioned} WHERE user_name = {user_name}"

dmurray 1y ago
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.
mcintyre1994 1y ago
This is how JavaScript does it with tagged template literals. Your sql there would just be a function that receives the array of strings/values and returns whatever.
masklinn 1y ago
This was considered and rejected: https://peps.python.org/pep-0750/#arbitrary-string-literal-prefixes https://peps.python.org/pep-0750/#arbitrary-string-literal-p...
dsego 1y ago
This is what JS does with tagged template literals. https://github.com/dsego/sql_tag https://github.com/dsego/sql_tag

mulmboy 1y ago

Are there string prefixes for i18n stuff?

Biganon 1y ago
They're probably talking about the convention of using _ as an alias for `translate`

albert_e 1y ago

"Yet another" is not my main worry The concept of prefixes itself feels a little deviant from readable code that is close to human language -- which is the spirit of Python

Timwi 1y ago
The single letter f or t does make it unnatural to read, but if it were sql"..." or html"...", I think that would help with that.
matusp 1y ago
Additionally, it will probably be confusing that it is called a t-string but it is actually a constructor for a Template object and not string at all. I would rather see a new special term `template` than this.
toxik 1y ago
Should have been a keyword. a = template "foo {bar}" As should raw and format.