Looks good. Would have been nice if they included a way to express type checking of the format_spec. That’s going to be an unnecessary source of runtime errors.
self-deleted
PEP 750: Tag Strings for Writing Domain-Specific Languages
21–30 of 99 posts
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#22My 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 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.
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#23My 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 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.
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#24For 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.
Given the names attached to the proposal, is this PEP actually up for debate?
Most of the critiques I am reading (with which I fully agree) is that this is more complexity in the language without sufficient payoff. There are now how many stupid or fancy ways to construct a Python string with a variable?
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#25My 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.
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#26My 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.
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.
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#27Looks good. Would have been nice if they included a way to express type checking of the format_spec. That’s going to be an unnecessary source of runtime errors.
self-deleted
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#28I 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.
That is probably a much better example than any of those present in the PEP. I quite like your example. I'm not sure I'd want to write code like that, but it shows the usefulness much more clearly.
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#29I LOVE tagged templates in JavaScript.
But in Python I could also imagine YET ANOTHER constant prefix, like t"", that returns a "template" object of some sort, and then you could do html(t"") or whatever. That is, it would be just like f"" but return an object and not a string so you could get at the underlying values. Like in JavaScript the ability to see the original backslash escaping would be nice, and as an improvement over JavaScript the ability to see the expressions as text would also be nice.
But the deferred evaluation seems iffy to me. Like I can see all the cool things one might do with it, but it also means you can't understand the evaluation without understanding the tag implementation.
Also I don't think deferred evaluation is enough to make this an opportunity for a "full" DSL. Something like a for loop requires introducing new variables local to the template/language, and that's really beyond what this should be, or what deferred evaluation would allow.
Re: PEP 750: Tag Strings for Writing Domain-Specific Languages
#30I 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.
[deleted]