Live data from Hacker News

PEP 750: Tag Strings for Writing Domain-Specific Languages

discuss.python.org

61–70 of 99 posts

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

#61

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

This is a problem with our industry that people get paid $$$ to use a language but at no point are they compelled to read the manual for that language from cover to cover.

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

#62

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…

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

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

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

#63
post #38

I would have loved to see Java introduce something similar to the IntelliJ @Language-annotation in the standard library but maybe they'll figure out the sweet spot in a future String Templating JEP. @Language("application/sql") String query = "SELECT 1"; @Language("application/graphql+json") String query = """ query HeroNameAndFriends { hero { name friends { name } } } """;

This is exactly how raw string literals together with StringSyntaxAttribute work in C#. It is very useful in e.g Regex syntax highlighting.

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

#64
post #60

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…

Python is too big to be a proper Lua replacement.

It was a reference to PyTorch, admittedly somewhat oblique.

Python is very popular for machine learning, in days gone past ML researchers used the Torch library in Lua. TensorFlow and PyTorch made Python the dominant language in that field.

https://en.wikipedia.org/wiki/PyTorch

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

#66
post #9
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.

I would probably use Jinja2.

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

#67
post #5
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.

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.

There already is a syntax for writing log messages where the arguments are only evaluated when they are needed. logger.debug("bla: %s" % myvar).

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

#68
post #7

I want this in Python: https://codecodeship.com/blog/2024-06-03-curl_req From the article: """ ~CURL[curl https://catfact.ninja/fact] |> Req.request!() This is actual code; you can run this. It will convert the curl command into a Req request and you will get a response back. This is really great, because we have been able to increase the expressiveness of the language. """

And somewhere there is the logic implemented to know what ~CURL is and what needs to happen with the part in square brackets, how it needs to be translated into a request call. And if that is merely an arguments equals arguments thingy, then it would be kind of useless, since there are usually more things one specifies when making a request from inside Python. Things like headers or whether or not to verify TLS certs, and that is not a 1 to 1 mapping between curl arguments and a requests call.

So I remain doubtful, as long as no way is shown to me, how the user of the language can define this syntactic abstraction themselves, which is unlikely to happen or exist in Python.

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

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

There already is a syntax for writing log messages where the arguments are only evaluated when they are needed. logger.debug("bla: %s" % myvar).

Actually, the % syntax eagerly evaluates the log string, you need to pass the variables as arguments to the logging function like this: logger.debug("bla: %s", myvar).

It's such a subtle difference that I only notice it when my IDE underlines it :/

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

#70
post #10
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.

I think at this point Python really needs to just settle down. I don't like this not because it's an intrinsically bad idea, but adding another thing to the already fairly large pile of things a Python user needs to know in order to read somebody else's code needs to be something that brings more benefits to the table than just "it slightly improves a particular type of function call". At the risk of riling some peop…

> there isn't even so much as a symbol they can search for on the internet, just an identifier smashed into a string.

That identifier has to come from somewhere. In order for this to work:

    greet"Hello {user}"
…they would have to first write something like:

    from some_tag_strings_library import greet
Also, in most IDEs, cmd-clicking on `greet` or similar would take them to its definition.
Post reply on HN