Hacker News Reader

Comment by dmart | Hacker News Reader

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.

View on HN

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 people up, this smells like Perl. Some poor Python user comes across

    greet"Hello {user}"

and there isn't even so much as a symbol they can search for on the internet, just an identifier smashed into a string.

But I guess Python and I parted ways on this matter quite a while ago. I like to joke about Katamari Dama-C++ but Python is starting to give it a run for its money. C++ is still in the lead, but Python is arguably sustainably moving more quickly on the "add more features" front.

My guess at the challenge is that the community who maintain and develop a language are by that very nature not in touch with what the complexity feels like for the average user.

Also it’s harder to do nothing than something.

That being said, I think this is partly abstract. I’ve just ignored a lot of new Python features without issue. And while I worried that they’d force me to learn new things to understand others’ code, that’s not really materialized.

> there isn't even so much as a symbol they can search for on the internet, just an identifier smashed into a string.

That identifier has to come from somewhere. In order for this to work:

    greet"Hello {user}"

…they would have to first write something like:

    from some_tag_strings_library import greet

Also, in most IDEs, cmd-clicking on `greet` or similar would take them to its definition.

How can you call a function that does this? html'<div id={id:int}>{content:HTML|str}</div>'.

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

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/

How is that a Janky workaround? It's not particularly ugly or verbose, nor does it seem to violate any python tenets.

Can you explain the difference?

Doing `html('<div>Hello {name}</div>')` 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'<div>Hello {name}</div>')` 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.

I would probably use Jinja2.

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.

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 straight up better version of template strings:

- the static strings and interpolations are not split and don't have to be awkwardly re-interpsersed which I've never found 100% trouble and 0% utility

- the lazy evaluation means it can be used for things like logging (which really want lazy evaluation), or meta-programmation (because you can introspect the callables, and you get the expression text)

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

The expressions for the data you want to log out can be expensive, so ideally you only want to compute them after you’ve checked if the logger was enabled for the level you need.

In most APIs this requires an explicit conditional check and the average developer will not think of it. This allows said check to be performed internally.

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

There already is a syntax for writing log messages where the arguments are only evaluated when they are needed. logger.debug("bla: %s" % myvar).

Actually, the % syntax eagerly evaluates the log string, you need to pass the variables as arguments to the logging function like this: logger.debug("bla: %s", myvar).

It's such a subtle difference that I only notice it when my IDE underlines it :/

You are right! I mixed them up as well. Here is a good source: https://blog.pilosus.org/posts/2020/01/24/python-f-strings-i... (not mine)

Reply on news.ycombinator.com