davepeck

Yeah. `join` has forever been backwards to me in Python and I still sometimes get it wrong the first time out.

Comprehensions, though -- they are perfection. :-)

> assuming an html() function would interpret plain Templates as HTML

Agreed; it feels natural to accept plain templates (and simple sequences of plain templates) as HTML; this is hinted at in the PEP.

> html(t"<ul>{map(lambda i: t"<li>{i}</li>", items)}</ul>")

Perhaps more idiomatically: html(t"<ul>{(t"<li>{i}</li>" for i in items)}</ul>")

> syntax highlighting and type-checking are keyed off the fact that a template can only ever have a single tag

Yes, this is a key difference and something we agonized a bit over as the PEP came together. In the (very) long term, I'm hopeful that we see type annotations used to indicate the expected string content type. In the nearer term, I think a certain amount of "clever kludginess" will be necessary in tools like (say) black if they wish to provide specialized formatting for common types.

> a special html() processing instruction could both emit server-rendered HTML and say, lit-html JavaScript templates that could be used to update the DOM client-side with new data

I'd love to see this and it's exactly the sort of thing I'm hoping emerges from PEP 750 over time. Please do reach out if you'd like to talk it over!

We wanted at least a couple examples that showed use of Python's newer pattern matching capabilities with the new Interpolation type. From this outsider's perspective, I'd say that developer instincts and aesthetic preferences are decidedly mixed here -- even amongst the core team! You can certainly write this as:

    def f(template: Template) -> str:
        return "".join(
            item if isinstance(item, str) else
            format(convert(item.value, item.conversion), item.format_spec)
            for item in template
        )

Or, y'know, several other ways that might feel more idiomatic depending on where you're coming from.

> doesn't specify the language of the template where the literal occurs

Yeah, something we spent a bunch of time considering. In the end, we decided it probably needed to stay out of scope for the PEP.

You're right that JavaScript has an easier time here. Most of the JS tools we looked at simply inspect the name of the tag and if it's (say) html, they attempt to color/format string content as HTML regardless of what the html() function actually does or the string's contents.

Currently, tools like black have no knowledge of types. I'm guessing some amount of kludging is to be expected on day one. But my hope is over the long term, we'll see a story emerge for how annotations can indicate the expected content type.

> were prompt templates for LLM prompt chaining a use case that influenced the design in any way

Maybe not directly, but the Python community is full of LLM users and so I think there's a general awareness of the issues.

For one thing, `f"something"` is of type `str`; `t"something"` is of type `string.templatelib.Template`. With t-strings, your code can know which parts of the string were dynamically substituted and which were not.

> the Template -> string function

There is no such function; Template.__str__() returns Template.__repr__() which is very unlikely to be useful. You pretty much have to process your Template instance in some way before converting to a string.

Yes, exactly. T-string arguments can't be unbound; they are eagerly evaluated.

Naming is hard; for instance, JavaScript also has its own template strings, which are also eagerly evaluated.

You might find the Python discussion forums ([0] and [1]) interesting; conversation that guides the evolution of PEPs happens there.

As Nick mentioned, PEP 750 had a long and winding road to its final acceptance; as the process wore on, and the complexities of the earliest cuts of the PEPs were reconsidered, the two converged.

[0] The very first announcement: https://discuss.python.org/t/pep-750-tag-strings-for-writing...

[1] Much later in the PEP process: https://discuss.python.org/t/pep750-template-strings-new-upd...

> Agreed, although this doesn't work as well for HTML or SQL that doesn't fit on one line.

PEP 750 t-strings literals work with python's tripe-quote syntax (and its lesser-used implicit string concat syntax):

    lots_of_html = t"""
       <div>
          <main>
             <h1>Hello</h1>
          </main>
       </div>
    """

My hope is that we'll quickly see the tooling ecosystem catch up and -- just like in JavaScript-land -- support syntax coloring and formatting specific types of content in t-strings, like HTML.

One place we landed with PEP 750 is that Template instances have no natural string rendering.

That is, you must process a Template in some way to get a useful string out the other side. This is why Template.__str__() is spec'd to be the same as Template.__repr__().

If you want to render a Template like an f-string for some reason, the pep750 examples repo contains an implementation of an `f(template: Template) -> str` method: https://github.com/davepeck/pep750-examples/blob/main/pep/fs...

This could be revisited, for instance to add `Template.format()` in the future.

PEP 750 doesn't directly address this because it's straightforward to simply wrap template creation in a function (or a lambda, if that's your style):

    def my_template(name: str) -> Template:
        return t"Hello, {name}"

Yes! PEP 750 landed exactly there: as a pythonic parallel to JavaScript's tagged template strings. I'm hopeful that the tooling ecosystem will catch up soon so we see syntax coloring, formatting of specific t-string content types, etc. in the future.

I'm not sure I agree with this analysis.

Template.__str__() is equivalent to Template.__repr__(), which is to say that these aren't f-strings in an important sense: you can't get a useful string out of them until you process them in some way.

The expectation is that developers will typically make use of well-established libraries that build on top of t-strings. For instance, developers might grab a package that provides an html() function that accepts Template instances and returns some Element type, which can then be safely converted into a string.

Stepping back, t-strings are a pythonic parallel to JavaScript's tagged template strings. They have many of the same advantages and drawbacks.

> I'm not sure if t-strings help here?

That's correct, they don't. Evaluation of t-string expressions is immediate, just like with f-strings.

Since we have the full generality of Python at our disposal, a typical solution is to simply wrap your t-string in a function or a lambda.

(An early version of the PEP had tools for deferred evaluation but these were dropped for being too complex, particularly for a first cut.)

Good news on that front! https://discuss.python.org/t/pep750-template-strings-new-upd...

Slowly but surely...

PEP 750 (still a proposal) adds "t-strings" Python. They're a simple extension of f-strings that give developers access to the static and interpolated parts of the string before they get combined into a final string. They're Python's answer to JavaScript template literals.

This allows writing code like:

  user_name = current_user.user_name  # something user-supplied and potentially unsafe
  foo: HTMLElement = html(t"<div>{user_name}</div>")  # wouldn't be safe with f-strings

where `html` is a normal function that takes a `Template` as an instance, and can return whatever it likes -- say, an `HTMLElement` rather than a `str`.

If PEP 750 does get accepted, eventually one hopes the community will introduce formatting, type checking, and LSP smarts for common kinds of t-strings, like HTML and maybe SQL, etc.

For what it’s worth: I believe they will prove ineffective at best, damaging at worst.

I believe disruptive change should be undertaken with a deep understanding of the history of an organization and a clear-eyed accounting of its successes and failures.

I see no evidence of this. I believe the current effort is, well, a bit more like a recklessly wielded chainsaw.

There are effective approaches to curbing fraud waste and abuse and ineffective or even damaging approaches. Which do you believe the current administration is engaged in?

Who said anything about a hidden agenda? Can you consider that the current efforts are outright foolish?

> The way you combat the creep of bureaucratic miasma is by regularly turning a critical eye inward

It certainly can’t hurt. Alas for the current moment, but it seems the eye we’re turning inward is as far from “critical” as can be.

And to be clear, they also flew to Taiwan and interviewed Morris in English for what appears to be the first time in over 15 years:

https://www.acquired.fm/episodes/tsmc-founder-morris-chang

A tiny bit of this (excellent!) interview led to the story we're all commenting on.

“Their apps are horrendous.”

I’ll give a counterpoint: with a subscription, Apple Music for iPad is quite literally the best personal music exploration/listening app on the market. A quiet room and good pair of headphones is all the rest you need.

Yeah, absolutely.

LLMs work best for code when both (a) there's sufficient relevant training data aka we're not doing something particularly novel and (b) there's sufficient context from the current codebase to pick up expected patterns, the peculiarities of the domain models, etc.

Drop (a) and get comical hallucinations; drop (b) and quickly find that LLMs are deeply mediocre at top-level architectural and framework/library choices.

Perhaps there's also a (c) related to precision. You can write code to issue a SQL query and return JSON from an API endpoint in multiple just-fine ways. Misplace a pthread_mutex_lock, however, and you're in trouble. I certainly don't trust LLMs to get things like this right!

(It's worth mentioning that "novelty" is a tough concept in the context of LLM training data. For instance, maybe nobody has implemented a font rasterizer in Rust before, but plenty of people have written font rasterizers and plenty of others have written Rust; LLMs seem quite good at synthesizing the two.)

I see less "painting as a luddite" in response to statements like this, and more... surprise. Mild skepticism, perhaps!

Your experience diverges from that of other experienced devs who have used the same tools, on probably similar projects, and reached different conclusions.

That includes me, for what it's worth. I'm a graybeard whose current work is primarily cloud data pipelines that end in fullstack web. Like most devs who have fully embraced LLMs, I don't think they are a magical panacea. But I've found many cases where they're unquestionably an accelerant -- more than enough to justify the cost.

I don't mean to say your conclusions are wrong. There seems to be a bimodal distribution amongst devs. I suspect there's something about _how_ these tools are used by each dev, and in the specific circumstances/codebases/social contexts, that leads to quite different outcomes. I would love to read a better investigation of this.

Cow Clicker 2025, Professional Edition. So good.

I always enjoy reading Maggie Appleton's blog posts: https://maggieappleton.com

And I always learn from the very deep signal processing fun on Absorptions: https://www.windytan.com

PEP 750 started its life in part as a result of learnings from pyxl [0], which used some clever hacks to add a JSX-like syntax to Python.

In the end, my instinct is that t-strings are the better more generic feature to add to the language itself today.

That said, I'd love to see the Python ecosystem get to the point where it's relatively easy to implement transpilers and get new grammars integrated with key tools (colorizers, formatters, linters, type checkers, etc). After that: let a thousand JSX-likes bloom.

[0] https://github.com/gvanrossum/pyxl3

To add some color to my comments: I also believe in your approach and I admire the work you and your team have done.

To sum up my entirely unoriginal opinions:

1. Mastodon has far better usability than any other Fediverse software I'm aware of

2. Despite this, usability is still a material coefficient of drag on Mastodon's growth

To be clear, I don't believe Mastodon has to or even should aspire to match the growth of other more centralized networks; only that usability is a drag on what would otherwise be natural growth for Mastodon itself.

I know you and your team spend a considerable amount of time and energy on usability, so I hope I'm not saying anything you don't already know infinitely better than I.