Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PEP 750: Tag Strings for Writing Domain-Specific Languages

discuss.python.org

Post reply on HN
Print view View original

41–50 of 99 posts

Re: PEP 750: Tag Strings for Writing Domain-Specific Languages

#41

Post by hombre_fatal »

mrweasel wrote: post #26
masklinn wrote: post #18

Earlier quoted context omitted.

> 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.

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.

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#protectin...

- postgres.js: https://github.com/porsager/postgres?tab=readme-ov-file#quer...

Re: PEP 750: Tag Strings for Writing Domain-Specific Languages

#43

Post by codethief »

masklinn wrote: post #16
Epa095 wrote: post #5

Earlier quoted context omitted.

This was my first thought as well. But an important difference is that the arguments are not eagerly evaluated, but they are passed as lambdas which can be evaluated if desired. This means that it can be used for example in log messages (if you don't want to evaluate the string at the wrong log levels). But is it worth it for that? Idk.

Even if eager evaluation it's already a very compelling way of managing basically every lightweight "templating" for safety: e.g. embedded dynamic HTML or SQL. `markupsafe` is great, but it's way too easy to perform formatting before calling it, especially with f-strings. That f-strings were "static" was by far my biggest criticism of it, given how useful I find JS's template strings. And this proposal seems like a s…

> - the lazy evaluation means it can be used for things like logging (which really want lazy evaluation)

Could you elaborate? I would find it rather surprising if my log messages don't contain the data at the very moment I invoke the logger.

Re: PEP 750: Tag Strings for Writing Domain-Specific Languages

#44

Post by masklinn »

codethief wrote: post #43
masklinn wrote: post #16

Earlier quoted context omitted.

Even if eager evaluation it's already a very compelling way of managing basically every lightweight "templating" for safety: e.g. embedded dynamic HTML or SQL. `markupsafe` is great, but it's way too easy to perform formatting before calling it, especially with f-strings. That f-strings were "static" was by far my biggest criticism of it, given how useful I find JS's template strings. And this proposal seems like a s…

> - the lazy evaluation means it can be used for things like logging (which really want lazy evaluation) Could you elaborate? I would find it rather surprising if my log messages don't contain the data at the very moment I invoke the logger.

The expressions for the data you want to log out can be expensive, so ideally you only want to compute them after you’ve checked if the logger was enabled for the level you need.

In most APIs this requires an explicit conditional check and the average developer will not think of it. This allows said check to be performed internally.

Re: PEP 750: Tag Strings for Writing Domain-Specific Languages

#45

Post by samatman »

I think this will turn out well. Julia has had this forever as string macros, and it has worked out rather nicely, features like `r"\d+"` for regex, and `raw"strings"` are just string macros. The set of all useful custom literal strings isn't bounded, so a lightweight mechanism to define them and make use of the results is a good thing.

Another kitchen sink to add to Python's world-class kitchen sink collection.

Re: PEP 750: Tag Strings for Writing Domain-Specific Languages

#46

Post by throwitaway1123 »

Too wrote: post #9
dmart wrote: post #3

I have to admit that at first glance I don’t like this. These seem to be essentially normal str -> Any functions, with some naming limitations due to the existing string prefixes special-cased in the language. I don’t feel like adding this additional complexity is worth being able to save two parentheses per function call.

How can you call a function that does this? html' {content:HTML|str} '. html() is not going to be equivalent.

For a practical example of this technique used in JS take a look at libraries like htm and lit-html: https://github.com/developit/htm

Re: PEP 750: Tag Strings for Writing Domain-Specific Languages

#47

Post by culi »

masklinn wrote: post #22
zarzavat wrote: post #19

Earlier quoted context omitted.

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 exc…

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.

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

Re: PEP 750: Tag Strings for Writing Domain-Specific Languages

#48

Post by daveFNbuck »

Too wrote: post #9
dmart wrote: post #3

I have to admit that at first glance I don’t like this. These seem to be essentially normal str -> Any functions, with some naming limitations due to the existing string prefixes special-cased in the language. I don’t feel like adding this additional complexity is worth being able to save two parentheses per function call.

How can you call a function that does this? html' {content:HTML|str} '. html() is not going to be equivalent.

Can you explain the difference?

Re: PEP 750: Tag Strings for Writing Domain-Specific Languages

#49

Post by orbisvicis »

This seems similar to my protostrings library [1] which I wrote years ago and mostly forgot about till now.

1. https://protostrings.readthedocs.io/en/latest/index.xhtml

iirc I wanted to encode state in a recursive-descent parser without additional complexity to the parser.

Similar in purpose not design; protostrings provides lazy and context-sensitive strings from the bottom up rather than this top-down template-style proposal, which I feel addresses most of the concerns here.

Re: PEP 750: Tag Strings for Writing Domain-Specific Languages

#50

Post by mumblemumble »

zarzavat wrote: post #19
mrweasel wrote: post #15

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…

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 exc…

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."

Post reply on HN