Python’s new t-strings

> Please engage with my point instead of criticizing trivialities.

Your complete misunderstanding of what's happening is not a triviality.

> The essential difference is that the language is referenced at the declaration site, not the usage site, which makes the syntax highlighting far easier.

Javascript has no built-in template tags beyond `String.raw`. If tooling has the capabilities to infer embedded language from arbitrary third party libraries, I would hope they have the ability to do utterly trivial flow analysis and realise that

    html(t"<something />")

means the template string is pretty likely to be HTML content.

Come on, you're just being rude for no good reason. A badly chosen variable name doesn't show a "complete misunderstanding". Yes, the variable should have been named `html_template` instead of `html_string` - how often do I have to acknowledge this before you accept it?

And it's obviously more complex to do syntax highlighting when the declaration site and usage site are possibly split apart by variable assignments etc. Yes, in the case you showed syntax highlighting is easy, but what if the `html` function takes more parameters, doesn't take the template as the first parameter, etc? There's a lot of possible complexity that tagged template literals don't have. Thus they are easier to do highlighting for. This is objectively true.

Yes. It's a weak heuristic, but it's EXACTLY the same weak heuristic that JS is applying!

IN other words, since custom template tags in JS *are literally just function calls* when a JS environment syntax highlights the code as HTML it's doing so based on an extremely weak heuristic (the identifier for the interpolation function is named "html"). Both Python and JS have the same problem.

Tagged template literals in JS have all that complexity. All of it. That tools you trust lie and pretend that's not the case doesn't make the language spec say anything different

No, they literally don't, because they don't support these features!

You can't split apart the declaration of the template literal and the "tagging". The tag is always part of the declaration, which it doesn't have to be in Python, as I've showed.

You can't pass additional parameters to the tag function, it's always just the template & values. In Python, you can pass as many parameters as you want to the usage site, e.g.

    some_value = html(True, t"<something />", 42)

I think his point would be clearer if we focused on typing the usages statically. Consider `html(this_is_a_sql_template)` vs. `html"SELECT * FROM ..."` or `thing_that_consumes_html_template_type(oops_a_sql_template_type)`.

It just sounds like you don't know JS very well, because in JS you can definitely split apart the declaration and the tag with ease. The thing implementing the tag is just a function after all: https://jsfiddle.net/rd2f1kot/

Sorry, but do just not want to understand what I'm talking about? Your example doesn't show what you're saying it does.

In Python you can do this:

    bar = "hello world"
    template = t"<something foo={bar} />"
    string = html(template)

This is simply not possible in JS, because the template literal always must have the tag attached. You can't split them apart. If you try:

    const bar = "hello world"
    const template = `<something foo=${bar} />`

you already have a string in the `template` variable. There's no access to the individual values anymore. It's already done. It's a string. No template. You can't pull apart the literal declaration and the tagging.

Are we now done with this ridiculous game of deliberate misunderstandings?

I just don't see the same thing as you. This is what you say is simply not possible:

  let passthrough = (...args) => args;
  let bar = "hello world";
  let template = passthrough`<something foo=${bar} />`;
  string = html(...template);

So now we have moved from "tagged template literals have all the complexity of Python templates" to "if you define a specific template tag and use that, you can replicate one feature of Python templates". No mention of the other example I mentioned (which, by the way, wasn't an exhaustive list).

Now, I'll just ignore that you're still deliberately misrepresenting me in the hopes of gaining some actual knowledge from this discussion - please show me: which editor supports syntax highlighting for the specific example you just mentioned? After all, that was the topic of discussion - not whether it's possible to delay "tagging", but whether it's easier to do syntax highlighting for JS template tags. Please show me an existing editor, IDE or git repo for a tool that would highlight your specific example based on the `html(...template)` call in line 4 (so no heuristics based on line 3). Surely you're not just throwing random examples at the wall to see what sticks, right? You've actually been following the discussion and are arguing in the context of it?

Sorry for some reason I can't reply to the deeper posts. Depth limit I guess. You asked which editors could support syntax highlighting once the tag and the content that needs to be syntax highlighted are split apart. Currently there are none, though I am writing one that will be able to.

Python should be able to detect the magic syntactic pattern just the same way JS does and use that for syntax higlighting. In JS the magic syntactic pattern for triggering HTML syntax highlighting is:

  html`<doc/>`

In Python the magic syntactic pattern would be:

  html(t"<doc />")

My point in showing that JS counterexample was to demonstrate that the real reason people don't do that kind of thing isn't that they can't, it's that they like having syntax highlighting. That means the approach should work just as well in Python. This is the case even though the heuristic involved is very weak. Changing the name of the identifier or breaking into multiple expressions would be enough to break the heuristic in either language, which is why I think it's a really weak heuristic and dangerous pitfall for developers who might mistake the coloring for information about how the runtime sees that data (which is normally what syntax highlighting is for)

Oh now I can reply. Thread continued above: https://news.ycombinator.com/item?id=43754585

If I may give you some advice: you could have made this point without telling me I don't know JS well, without misrepresenting me and without wasting both of our time by just making this point from the start. Because you are technically correct that, in the limited case of a template immediately being passed to a function, syntax highlighting can use the same heuristics that are currently used in JS. But, as I assumed previously, in doing so you're simply ignoring my point: syntax highlighting for tagged template literals isn't applicable to only a subset of uses because they are by design less complex. Your counter example was using a different template tag and not using the actual tag as a template tag, which obviously doesn't work in the context of syntax highlighting for that template tag.

Had you not played games with this technicality, we could both have saved a lot of time. Hope you had fun I guess.