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

81–90 of 99 posts

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

#81

Post by pauleveritt »

mrweasel wrote: post #28
Too wrote: post #9

Earlier quoted context omitted.

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.

We originally had a long HTML tutorial in the PEP. It was extracted. It's here, if anyone is interested: https://pauleveritt.github.io/tagstr-site/htmlbuilder.html

Companion repo with: JupyterLite playground, Docker images, other material. https://github.com/pauleveritt/tagstr-site

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

#82

Post by pauleveritt »

throwitaway1123 wrote: post #46
Too wrote: post #9

Earlier quoted context omitted.

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

(PEP co-author here) The htm folks did a Python implementation: https://pypi.org/project/htm/

It required a janky workaround for the absence of this PEP: https://pypi.org/project/tagged/

I used these to investigate ideas about component-driven development: https://viewdom.readthedocs.io/en/latest/

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

#83

Post by pauleveritt »

daveFNbuck wrote: post #48
Too wrote: post #9

Earlier quoted context omitted.

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?

Doing `html('Hello {name}')` would be possible. I have a system that's based on it. Two issues:

- No tooling in Python will do anything with the string, so DX suffers. - Evaluating the variable requires frame evaluation, which is...problematic.

You could do `html(f'Hello {name}')` and get f-string coding assistance. But you'd also get immediate evaluation. There's nothing the `html` function can do with the `{name}` part.

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

#84

Post by pauleveritt »

ianbicking wrote: post #29

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

Cool to see you jump in, Ian.

I don't particularly mind the prefix thing. It came up in the PEP discussion, as did choice of backticks to indicate this is different. But JS template literals -> tagged template literals shows, you can get from A to B without a fundamental change.

I'm very interested though in the deferred part. I agree that there is complexity. I weigh that, though, against the complexity of existing Python HTML templating, where finding out what just happened is...harder.

I think we can get a TSX-level of DX out of this. And maybe a Lit level of composition. Agree that it is non-zero complexity.

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

#85

Post by pauleveritt »

DataDive wrote: post #76
RhysU wrote: post #51

Earlier quoted context omitted.

f("Consider...") greet("Hello {name}") What was wrong with the standard way to write function application? Python is sufficiently dynamic that an implementation of greet(...) can look up one level to resolve {name}, right? That's why Python will forever run like a dog. Might as take advantage of it to build such capabilities in user space. This crap is going to end up inside f-strings inside tag-strings inside f-stri…

Your reply appears to indicate that you do not properly understand the new proposed feature. It is most certainly not just about dropping two parentheses. > Tag strings extract more than just a callable from the Interpolation. They also provide Python string formatting info, as well as the original text. The feature is akin to moving print from a keyword to a function. That change also made a huge difference in that…

(PEP co-author here.) You've described it well. As the "How to teach it section" emphasizes, we'd like consumers of tag functions to just think of it as an f-string with other stuff that happens before evaluation.

From their POV, inside the quotes, what you know about f-strings, you know here as well.

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

#86

Post by mumblemumble »

pauleveritt wrote: post #78
mumblemumble wrote: post #50

Earlier quoted context omitted.

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…

Hi, I'm a PEP author. The hope was that users would say "I know f-string syntax so I know this syntax." Similar to JS and its template literals -> tagged template literal jump.

That would be an easy mental jump for skilled python users, but I think that it would be surprising for many less experienced users. Just giving it a function call syntax would be more in line with the principles established in PEP-20 IMO.

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

#87

Post by RhysU »

pauleveritt wrote: post #85
DataDive wrote: post #76

Earlier quoted context omitted.

Your reply appears to indicate that you do not properly understand the new proposed feature. It is most certainly not just about dropping two parentheses. > Tag strings extract more than just a callable from the Interpolation. They also provide Python string formatting info, as well as the original text. The feature is akin to moving print from a keyword to a function. That change also made a huge difference in that…

(PEP co-author here.) You've described it well. As the "How to teach it section" emphasizes, we'd like consumers of tag functions to just think of it as an f-string with other stuff that happens before evaluation. From their POV, inside the quotes, what you know about f-strings, you know here as well.

Why could you not know these things without a language feature?

> ...other stuff that happens before evaluation...

A greet(string) function could parse the string and resolve the names itself:

parsed = parser(string)

resolved = resolver(parsed)

return formatter(resolved)

If you hate boilerplate, make the first two steps into a decorator.

A PEP introducing a grand unified theory of magic (tag strings) isn't inherently better than the status quo of some (f-string) magic. Less magic is better.

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

#88

Post by pauleveritt »

mumblemumble wrote: post #86
pauleveritt wrote: post #78

Earlier quoted context omitted.

Hi, I'm a PEP author. The hope was that users would say "I know f-string syntax so I know this syntax." Similar to JS and its template literals -> tagged template literal jump.

That would be an easy mental jump for skilled python users, but I think that it would be surprising for many less experienced users. Just giving it a function call syntax would be more in line with the principles established in PEP-20 IMO.

If I understand correctly, you'd prefer what other commenters have said for `html(i"Hello {name}")`?

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

#89

Post by [deleted] »

DataDive wrote: post #76
RhysU wrote: post #51

Earlier quoted context omitted.

f("Consider...") greet("Hello {name}") What was wrong with the standard way to write function application? Python is sufficiently dynamic that an implementation of greet(...) can look up one level to resolve {name}, right? That's why Python will forever run like a dog. Might as take advantage of it to build such capabilities in user space. This crap is going to end up inside f-strings inside tag-strings inside f-stri…

Your reply appears to indicate that you do not properly understand the new proposed feature. It is most certainly not just about dropping two parentheses. > Tag strings extract more than just a callable from the Interpolation. They also provide Python string formatting info, as well as the original text. The feature is akin to moving print from a keyword to a function. That change also made a huge difference in that…

[deleted]

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

#90

Post by pauleveritt »

RhysU wrote: post #87
pauleveritt wrote: post #85

Earlier quoted context omitted.

(PEP co-author here.) You've described it well. As the "How to teach it section" emphasizes, we'd like consumers of tag functions to just think of it as an f-string with other stuff that happens before evaluation. From their POV, inside the quotes, what you know about f-strings, you know here as well.

Why could you not know these things without a language feature? > ...other stuff that happens before evaluation... A greet(string) function could parse the string and resolve the names itself: parsed = parser(string) resolved = resolver(parsed) return formatter(resolved) If you hate boilerplate, make the first two steps into a decorator. A PEP introducing a grand unified theory of magic (tag strings) isn't inherently…

If the string is an f-string, it is immediately evaluated and you no longer have access to the interpolation info for a resolver.

If the string is not an f-string, you get no help from Python tooling.

In both cases, you have to use frame hacks to get back to the scope, which has negative consequences.

Post reply on HN