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

71–80 of 99 posts

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

#71

Post by laurent_du »

zarzavat wrote: post #61
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…

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.

For real. How long does it realistically take to stay informed of the language's evolution? Literally a few hours every couple months, not much more.

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

#74

Post by spankalee »

Nullabillity wrote: post #54
spankalee wrote: post #36

Earlier quoted context omitted.

I wonder if each of the string args is stable? Then you could just use the first as the key. The JS API where the strings are separate might seem awkward at first, but it ends up being a really elegant design. Deferred evaluation is really powerful and I wish JS had it. It's one of the reasons why Solid has a custom JSX compiler and doesn't use tagged literals... to get the-evaluation you need to user to pass in clos…

Python does string interning, so that seems.. dangerous.

Most managed languages do string interning. But the object passed as the string value doesn't seem to be just a string. It's wrapped in another object, which could have callsite identity.

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

#75

Post by pauleveritt »

zoogeny wrote: post #37

I've seen this feature used responsibly and to good effect in a few TypeScript projects so I understand why it would be desirable in Python.

Hi, I'm one of the PEP authors. This is precisely my primary interest. TSX makes for a good HTML templating experience. Python templating approaches usually create a parallel universe of scope, syntax, imports, linting, type checking, IDE assistance, etc. where little of Python tooling exists.

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

#76

Post by DataDive »

RhysU wrote: post #51
DataDive wrote: post #39

Excellent idea, I don't get the criticism, If a syntax such as f"{variable}" is already a feature - and turned out to be a popular one - why shouldn't we be able to add our own custom "f"s? Because that is what this is about. It might make generating output even simpler. I applaud the idea and am pleased to see that Python keeps innovating!

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 it unified the output stream and avoided having undefined objects like a "print" keyword.

Here, you can think of the feature as moving an "f" string from a hardcoded, predetermined definition to a generalizable and programmable behavior.

If "f" strings have become so popular so quickly it means they addressed a pressing need. It is logical to assume that a programmable version of an "f" string would be even more useful.

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

#77

Post by pauleveritt »

mrweasel wrote: post #15

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…

Hi, I'm one of the PEP authors. Your point covers one of my motivations, so here's a bit about what interests me. Mainly, "Jinja2 and Django templates are pretty much just using Python."

I see things differently. In those, nearly everything is a parallel universe where things aren't Python. Scope rules. Imports. Control flow. Calling things. Navigation. Refactoring. Linting. Therefore, Python tooling can't really help much. Tools have to write special rules to help on each template language and framework.

Instead, imagine if Black, Ruff, mypy, pyupgrade, and IDEs could treat the template part as software.

I realize I'm describing "people who want Python tooling", which might be a minority. I also realize there's pushback about additions to Python. That said, I think TSX and friends have shown -- there's lots we can do to improve Python web development.

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

#78

Post by pauleveritt »

mumblemumble wrote: post #50
zarzavat wrote: post #19

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…

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.

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

#79

Post by pauleveritt »

mrweasel wrote: post #23
zarzavat wrote: post #19

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

I'd be interested in chatting with you sometime on duck typing (protocols) and how it (along with this PEP) could bring component-driven development to Python.

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

#80

Post by pauleveritt »

mrweasel wrote: post #26
masklinn wrote: post #18

Earlier quoted context omitted.

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

I actually have a stuff based on tagged (https://pypi.org/project/tagged/) and htm.py (https://github.com/jviide/htm.py) So from a web development perspective, I can likely answer, if it is germane.
Post reply on HN