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…
PEP 750: Tag Strings for Writing Domain-Specific Languages
61–70 of 99 posts
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#62My 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.
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
#63I 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 } } } """;
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#64Earlier 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.
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.
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#65Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#66I 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.
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#67I 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.
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#68I 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. """
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
#69Earlier 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).
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
#70I 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…
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.