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

51–60 of 99 posts

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

#51

Post by RhysU »

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-strings inside... We have a language. Don't extend it to express what it's perfectly capable of expressing already.

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

#52

Post by skywhopper »

codethief wrote: post #43
masklinn wrote: post #16

Earlier quoted context omitted.

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

> - the lazy evaluation means it can be used for things like logging (which really want lazy evaluation) Could you elaborate? I would find it rather surprising if my log messages don't contain the data at the very moment I invoke the logger.

You can’t get log4j-style security crises with eager evaluation.

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

#54

Post by Nullabillity »

spankalee wrote: post #36
svieira wrote: post #35

Earlier quoted context omitted.

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

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

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

#55

Post by pansa2 »

Off-topic, but when did Python become so... verbose? From the PEP:

    def greet(*args: Decoded | Interpolation) -> str:
        result = []
        for arg in args:
            match arg:
                case Decoded() as decoded:
                    result.append(decoded)
                case Interpolation() as interpolation:
                    value = interpolation.getvalue()
                    result.append(value.upper())

        return f"{''.join(result)}!"
Isn't that just this?

    def greet(*args):
        def convert(arg):
            return arg.getvalue().upper() if hasattr(arg, getvalue) else arg

        return ''.join(convert(arg) for arg in args) + '!'

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

#56

Post by Groxx »

... is this any different than a function like this:

    greet("hello {world}")
which walks the call stack to find the variables, and uses them as locals / arguments?

If so: why not just do that? I would expect the performance to be kinda terrible compared to a language-intrinsic, but this hardly seems like a thing worth truly optimizing. And if it's too costly at runtime, someone can implement a parse-time AST rewriter, like many Python things already do. Heck, that example's `assert` is probably using pytest (because everyone uses pytest) and it's doing exactly this already, and it isn't a language feature, it's just a normal library using normal Python features.

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

#57

Post by KolenCh »

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…

A perfect use case for chatbots to answer them instead.

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

#58

Post by orbisvicis »

pansa2 wrote: post #55

Off-topic, but when did Python become so... verbose? From the PEP: def greet(*args: Decoded | Interpolation) -> str: result = [] for arg in args: match arg: case Decoded() as decoded: result.append(decoded) case Interpolation() as interpolation: value = interpolation.getvalue() result.append(value.upper()) return f"{''.join(result)}!" Isn't that just this? def greet(*args): def convert(arg): return arg.getvalue().upp…

Guido has been pretty vocal about his preference for loops over comprehensions, so it's just a matter of personal preference. But they're also trying to use the newer pattern matching rather than duck-typing, and comprehensions don't support pattern matching (isinstance doesn't count).

The pattern matching stuff is neat but seems pretty half-baked. Only available to imperative code and restricted in what can be matched. I wish they'd finish fleshing it out because right now it feels tacky.

Actually my number one wish forever has been that functions would become actual first-class objects, able to be defined and manipulated during runtime at the syntax level. Would have been great for so much of my code, and the original decorator module. Things are better with the new inspect module but it's still ridiculously clunky.

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

#59

Post by Spivak »

The much bigger feature here is buried under the DSL stuff. Python is effectively implementing a method of lazy evaluation of function arguments! I thought I would never see the day! It's crazy that if this PEP is accepted, functions in Python will actually be a special case of f-strings.

I hope they eventually grant this power to regular functions because otherwise I know folks will end up myfunc"{arg1},{arg2}" to get that feature.

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

#60

Post by diffxx »

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

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…

Python is too big to be a proper Lua replacement.
Post reply on HN