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

31–40 of 99 posts

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

#31

Post by [deleted] »

jerf wrote: post #10
dmart wrote: post #3

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

[deleted]

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

#32

Post by spankalee »

I tried skimming the PEP while I could, but it seems like this might be missing a couple of the features that make JS tagged template literals work so well:

- tags get a strings array that's referentially stable across invocations. This can function as a cache key to cache strings parsing work. - tags can return any kind of value, not just a string. Often you need to give structured data to another cooperating API.

Deferred evaluation of expressions is very cool, and would be really useful for reactive use-cases, assuming they can be evaluated multiple times.

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

#34

Post by Hamuko »

I hate the idea of reusing the existing string/bytes prefixes for something that is completely different. How is someone expected to know that br"" is inherent Python syntax and my"" is essentially an user-defined function? And the only way to ever add a new prefix into the language (like f"" was added quite recently) is to wait until Python 4, at which point we'll need 3to4 to automatically rename all of your old tag strings that are now conflicting and people will bitch about how badly major Python upgrades suck.

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

#35

Post by svieira »

spankalee wrote: post #32

I tried skimming the PEP while I could, but it seems like this might be missing a couple of the features that make JS tagged template literals work so well: - tags get a strings array that's referentially stable across invocations. This can function as a cache key to cache strings parsing work. - tags can return any kind of value, not just a string. Often you need to give structured data to another cooperating API. D…

The string array is not referentially stable across invocations and cannot be because there is a single argument array containing both the "static" bits and the "dynamic" bits. So you can't use it the way that JS' `static_strings` argument can be used as a key in a `WeakMap`.

Tags can return any kind of value, so there's that.

Deferred evaluations can be evaluated multiple times and is in fact one of the biggest foot-guns in this API (in my opinion).

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

#36

Post by spankalee »

svieira wrote: post #35
spankalee wrote: post #32

I tried skimming the PEP while I could, but it seems like this might be missing a couple of the features that make JS tagged template literals work so well: - tags get a strings array that's referentially stable across invocations. This can function as a cache key to cache strings parsing work. - tags can return any kind of value, not just a string. Often you need to give structured data to another cooperating API. D…

The string array is not referentially stable across invocations and cannot be because there is a single argument array containing both the "static" bits and the "dynamic" bits. So you can't use it the way that JS' `static_strings` argument can be used as a key in a `WeakMap`. Tags can return any kind of value, so there's that. Deferred evaluations can be evaluated multiple times and is in fact one of the biggest foot…

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 closures, which is cumbersome.

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

#38

Post by tofflos »

I 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

#39

Post by DataDive »

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!

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

#40

Post by akklrgaG »

jtwaleson wrote: post #11

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.

Why would anyone do this? You risk being banned and defamed if you lack deference or exceed your allotment of five messages per thread.

Moreover, Python has resume-driven development and people with a financial or reputational interest will get their new toys in no matter what.

You would just contribute to the appearance of democracy.

Post reply on HN