For people adding insightful critique on the PEP on HN (I saw some on this thread already), please ensure your opinion is represented in the PEP thread itself too.
PEP 750: Tag Strings for Writing Domain-Specific Languages
11–20 of 99 posts
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#12[deleted]
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#13I 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…
My guess at the challenge is that the community who maintain and develop a language are by that very nature not in touch with what the complexity feels like for the average user.
Also it’s harder to do nothing than something.
That being said, I think this is partly abstract. I’ve just ignored a lot of new Python features without issue. And while I worried that they’d force me to learn new things to understand others’ code, that’s not really materialized.
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#14I 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.
[deleted]
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#15My 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.
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#16I 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.
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 straight up better version of template strings:
- the static strings and interpolations are not split and don't have to be awkwardly re-interpsersed which I've never found 100% trouble and 0% utility
- the lazy evaluation means it can be used for things like logging (which really want lazy evaluation), or meta-programmation (because you can introspect the callables, and you get the expression text)
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#17This like a bad idea on the first glance? Maybe I don't get the whole pitch here? It just doesn't seem worth it to define a whole new thing just to abstract over a format() function call. The laziness might be interesting, but I feel like "lazy strings" might be all that's needed here. Laziness and validation (or custom string formatting logic) are separate concerns and should be separated.
> It just doesn't seem worth it to define a whole new thing just to abstract over a format() function call.
That could also be leveraged at f-strings themselves.
> Laziness and validation (or custom string formatting logic) are separate concerns and should be separated.
In which case the one to move out is the laziness not the customised interpolation. Because the latter is the one that's necessary for safer dynamic SQL or HTML or whatever.
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#18My 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…
> 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.
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#19My 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 excited for it.
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#20Yikes. Don't get me wrong, I totally understand the reasoning why this would be useful (though I violently disagree with the idea of deferring the evaluation of the contained expressions), but it's also so very kitchensinky and adds so little over just calling a function (which doesn't require a 20-page explainer, as everyone already knows how function calls work). It also promotes using what looks like string interp…
> This seems really awkward to me for building stuff like the suggested use cases of XML/HTML or SQL templating.
Compared to what?
At the end of the day you're still doing string formatting, if you want parsing, then you'd feed the item into a parser, which this doesn't preclude.
The interface sounds a lot better than JS's anyway, as that completely separates the literal strings and the interpolations so you have to re-intersperse them which is muggy.
> interpolations become four-tuple-like
They become an Interpolation object, which can be unpacked if you find that more convenient, but you can access the members if you prefer:
- 0 is getvalue is the callable to retrieve the evaluated expression
- 1 is expr is the raw text form of the expression
- 2 is conv is the !conversion tag (s, r, or a)
- 3 is format_spec