3 ms·

My issue with this that is will eventually sneak into libraries and the users of that library would be expected to use these tag strings all over the place to u

My issue with this that is will eventually sneak into libraries and the users of that library would be expected to use these tag strings all over the place to utilize the library. This prevents people from having a uniform coding style and make code harder to read. The concern isn't having features that will make it easier to write DSLs, my problem is that people will misuse it in regular Python projects. I know that one of the authors are Guido, but I'm not buying the motivation. Jinja2 and Django template are pretty much just using Python, it's not really much of an issue, and I don't believe that business logic should exist in your templates anyway. As for the SQL argument, it will still be possible for people to mess it up, even with Tag Strings, unless you completely remove all legacy code. The issue here isn't that the existing facilities aren't good enough, it's that many developers aren't aware of the concepts, like prepared statements. If developers aren't reading the docs to learn about prepared statements, why would they do so for some DSL developed using tag strings? Obviously Guido is a better developer than me any day, so I might be completely wrong, but this doesn't feel right. I've seen tools developed to avoid just doing the proper training, and the result is always worse.

masklinn 2y ago
> If developers aren't reading the docs to learn about prepared statements, why would they do so for some DSL developed using tag strings? Because you've deprecated the "bare string" interface so they can't use that anymore, or it's hidden deep into the utility modules.
- mrweasel 2y ago
  But you could do that already, could you not? Django does. Its just not really SQL anymore then. Someone else also pointed out that you could just do this with functions. It seems like a very fancy way of avoiding using (). I don't know, maybe show me how that would solve the issue of unsafe SQL and I'd be more easily convinced.
  - hombre_fatal 2y ago
    Because it turns into a parameterized SQL query. This already exists in the Javascript ecosystem: sql`select * from users where id = ${id}` Turns into: { query: 'select * from users where id = $1', values: [id] } So if you tried an injection like this: sql`select * from users ${'where id = 3'}` It turns into an invalid statement since "where id = 3" cannot exist as a parameterized value for the same reason this doesn't work: { query: 'select * from users $1', values: ['where id = 3'] } Where you go from here is to offer a query(statement) function that requires the use of the tag string so that you can't accidentally pass in a normal string-interpolated string. Examples: - slonik: https://github.com/gajus/slonik?tab=readme-ov-file#protecting-against-unsafe-value-interpolation https://github.com/gajus/slonik?tab=readme-ov-file#protectin... - postgres.js: https://github.com/porsager/postgres?tab=readme-ov-file#queries https://github.com/porsager/postgres?tab=readme-ov-file#quer...
  - pauleveritt 2y ago
    I actually have a stuff based on tagged (https://pypi.org/project/tagged/ https://pypi.org/project/tagged/) and htm.py (https://github.com/jviide/htm.py https://github.com/jviide/htm.py) So from a web development perspective, I can likely answer, if it is germane.
zarzavat 2y ago
I feel like there’s a clash of cultures. There’s Python the scripting language, replacement for bash scripts, R and Lua. Then there’s Python the serious software development language. Where people have style guides, code review, test coverage, and projects with more than one directory. I understand why people in the second group are fearful of this feature and DSLs in general. I’m in the first group and I’m quite excited for it.
- masklinn 2y ago
  I'm in the second group and I'm very excited for it, getting the linting right to prevent people doing wild formatting into dangerous string-based APIs is not easy, this provides an opportunity to make it much easier and safer.
  - culi 2y ago
    And the second group is already likely to have a linter set up. The author's fears about this showing up in library code is still valid though
- mrweasel 2y ago
  I can get behind that. I see some of the same issue in regards to type annotation. I'm heavily leaning into the dynamic / duck-typing aspects of Python, so type annotation is often complicated or very broad, to the point where it's a little redundant. If you're not really writing code like that, type annotation is an awesome addition to the language. I'd be very interested in seeing where this goes, it certainly has it's uses, but there's also a ton of projects where it really doesn't belong.
  - pauleveritt 2y ago
    I'd be interested in chatting with you sometime on duck typing (protocols) and how it (along with this PEP) could bring component-driven development to Python.
- mumblemumble 2y ago
  I'm in both groups and I'm getting tired of how Python's syntax additions increasingly turn it into a mechanism for mid-level engineers to assert their dominance over colleagues by writing code that only people who have been deeply immersed in Python for years can understand. Our Python users' Slack channel at work is already overcrowded with messages to the effect of, "halp what's this syntax how does this code work."
MrBuddyCasino 2y ago
No IMO this is correct. DSLs often lead to heterogeneous code styles that are hard to reason about. Simpler is usually better.
- d0mine 2y ago
  bash -- DSL for invoking subprocesses :: what you rather see in a code review: one-line shell pipeline or equivalent Python code? https://stackoverflow.com/questions/295459/how-do-i-use-subprocess-popen-to-connect-multiple-processes-by-pipes https://stackoverflow.com/questions/295459/how-do-i-use-subp... sh-like DSL on top of Python literal strings that doesn't invoke shell might be interesting (pep may help) regex -- DSL for search/replace in text. Useful in moderation jq -- DSL for search/replace in json. Useful on the command-line xpath -- DSL for searching trees (hierarchy) sql/xslt -- I would rather read Python most of the time instead but sometimes it is helpful to have an option of writing SQL directly (pep may help) toml/json -- writing Python directly is preferable (in the context of .py file) markdown -- DSL for writing markup (instead of html/word). I wouldn't say no to inline docstring rendering in Python code (pep may help). The same for (subset of) latex -- for math formulas `$e^{i \pi} -1 = 0$` dot/plantuml (ebnf, sequence diagrams, etc) could be useful for literate programming-heavy style.
pauleveritt 2y ago
Hi, I'm one of the PEP authors. Your point covers one of my motivations, so here's a bit about what interests me. Mainly, "Jinja2 and Django templates are pretty much just using Python." I see things differently. In those, nearly everything is a parallel universe where things aren't Python. Scope rules. Imports. Control flow. Calling things. Navigation. Refactoring. Linting. Therefore, Python tooling can't really help much. Tools have to write special rules to help on each template language and framework. Instead, imagine if Black, Ruff, mypy, pyupgrade, and IDEs could treat the template part as software. I realize I'm describing "people who want Python tooling", which might be a minority. I also realize there's pushback about additions to Python. That said, I think TSX and friends have shown -- there's lots we can do to improve Python web development.

masklinn 2y ago

> If developers aren't reading the docs to learn about prepared statements, why would they do so for some DSL developed using tag strings? Because you've deprecated the "bare string" interface so they can't use that anymore, or it's hidden deep into the utility modules.

mrweasel 2y ago
But you could do that already, could you not? Django does. Its just not really SQL anymore then. Someone else also pointed out that you could just do this with functions. It seems like a very fancy way of avoiding using (). I don't know, maybe show me how that would solve the issue of unsafe SQL and I'd be more easily convinced.
- hombre_fatal 2y ago
  Because it turns into a parameterized SQL query. This already exists in the Javascript ecosystem: sql`select * from users where id = ${id}` Turns into: { query: 'select * from users where id = $1', values: [id] } So if you tried an injection like this: sql`select * from users ${'where id = 3'}` It turns into an invalid statement since "where id = 3" cannot exist as a parameterized value for the same reason this doesn't work: { query: 'select * from users $1', values: ['where id = 3'] } Where you go from here is to offer a query(statement) function that requires the use of the tag string so that you can't accidentally pass in a normal string-interpolated string. Examples: - slonik: https://github.com/gajus/slonik?tab=readme-ov-file#protecting-against-unsafe-value-interpolation https://github.com/gajus/slonik?tab=readme-ov-file#protectin... - postgres.js: https://github.com/porsager/postgres?tab=readme-ov-file#queries https://github.com/porsager/postgres?tab=readme-ov-file#quer...
- pauleveritt 2y ago
  I actually have a stuff based on tagged (https://pypi.org/project/tagged/ https://pypi.org/project/tagged/) and htm.py (https://github.com/jviide/htm.py https://github.com/jviide/htm.py) So from a web development perspective, I can likely answer, if it is germane.

zarzavat 2y ago

I feel like there’s a clash of cultures. There’s Python the scripting language, replacement for bash scripts, R and Lua. Then there’s Python the serious software development language. Where people have style guides, code review, test coverage, and projects with more than one directory. I understand why people in the second group are fearful of this feature and DSLs in general. I’m in the first group and I’m quite excited for it.

masklinn 2y ago
I'm in the second group and I'm very excited for it, getting the linting right to prevent people doing wild formatting into dangerous string-based APIs is not easy, this provides an opportunity to make it much easier and safer.
- culi 2y ago
  And the second group is already likely to have a linter set up. The author's fears about this showing up in library code is still valid though
mrweasel 2y ago
I can get behind that. I see some of the same issue in regards to type annotation. I'm heavily leaning into the dynamic / duck-typing aspects of Python, so type annotation is often complicated or very broad, to the point where it's a little redundant. If you're not really writing code like that, type annotation is an awesome addition to the language. I'd be very interested in seeing where this goes, it certainly has it's uses, but there's also a ton of projects where it really doesn't belong.
- pauleveritt 2y ago
  I'd be interested in chatting with you sometime on duck typing (protocols) and how it (along with this PEP) could bring component-driven development to Python.
mumblemumble 2y ago
I'm in both groups and I'm getting tired of how Python's syntax additions increasingly turn it into a mechanism for mid-level engineers to assert their dominance over colleagues by writing code that only people who have been deeply immersed in Python for years can understand. Our Python users' Slack channel at work is already overcrowded with messages to the effect of, "halp what's this syntax how does this code work."

MrBuddyCasino 2y ago

No IMO this is correct. DSLs often lead to heterogeneous code styles that are hard to reason about. Simpler is usually better.

d0mine 2y ago
bash -- DSL for invoking subprocesses :: what you rather see in a code review: one-line shell pipeline or equivalent Python code? https://stackoverflow.com/questions/295459/how-do-i-use-subprocess-popen-to-connect-multiple-processes-by-pipes https://stackoverflow.com/questions/295459/how-do-i-use-subp... sh-like DSL on top of Python literal strings that doesn't invoke shell might be interesting (pep may help) regex -- DSL for search/replace in text. Useful in moderation jq -- DSL for search/replace in json. Useful on the command-line xpath -- DSL for searching trees (hierarchy) sql/xslt -- I would rather read Python most of the time instead but sometimes it is helpful to have an option of writing SQL directly (pep may help) toml/json -- writing Python directly is preferable (in the context of .py file) markdown -- DSL for writing markup (instead of html/word). I wouldn't say no to inline docstring rendering in Python code (pep may help). The same for (subset of) latex -- for math formulas `$e^{i \pi} -1 = 0$` dot/plantuml (ebnf, sequence diagrams, etc) could be useful for literate programming-heavy style.

pauleveritt 2y ago

Hi, I'm one of the PEP authors. Your point covers one of my motivations, so here's a bit about what interests me. Mainly, "Jinja2 and Django templates are pretty much just using Python." I see things differently. In those, nearly everything is a parallel universe where things aren't Python. Scope rules. Imports. Control flow. Calling things. Navigation. Refactoring. Linting. Therefore, Python tooling can't really help much. Tools have to write special rules to help on each template language and framework. Instead, imagine if Black, Ruff, mypy, pyupgrade, and IDEs could treat the template part as software. I realize I'm describing "people who want Python tooling", which might be a minority. I also realize there's pushback about additions to Python. That said, I think TSX and friends have shown -- there's lots we can do to improve Python web development.