Putting aside template strings themselves for the moment, I'm stunned by some of the code in this PEP. It's so verbose! For example, "Implementing f-strings with t-strings":

    def f(template: Template) -> str:
        parts = []
        for item in template:
            match item:
                case str() as s:
                    parts.append(s)
                case Interpolation(value, _, conversion, format_spec):
                    value = convert(value, conversion)
                    value = format(value, format_spec)
                    parts.append(value)
        return "".join(parts)

By contrast, here's the equivalent Ruby:

    def f(template) = template.map { |item|
            item.is_a?(Interpolation) ? item.value.convert(item.conversion).format(item.format_spec) : item
        }.join

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
        )

This is how Python has always been. It's more verbose and IMO easier to grok, but it still lets you create expressive DSLs like Ruby does.

Python has always been my preference, and a couple of my coworkers have always preferred Ruby. Different strokes for different folks.

A compromise version:

    def _f_part(item) -> str:
        match item:
            case str() as s:
                return s
            case Interpolation(value, _, conversion, format_spec):
                return format(convert(value, conversion), format_spec)

    def f(template: Template) -> str:
        return ''.join(map(_f_part, template))

I very frequently use this helper-function (or sometimes a generator) idiom in order to avoid building a temporary list to `.join` (or subject to other processing). It separates per-item processing from the overall algorithm, which suits my interpretation of the "functions should do one thing" maxim.

The Python version is straightforward to read and understand to a programmer of any language. The Ruby version is an idiosyncratic symbol soup.

If I were tasked to modify the Python version to say, handle the case where `item` is an int, it would be immediately obvious to me that all I need to do is modify the `match` statement with `case int() as i:`, I don't even need to know Python to figure that out. On the other hand, modifying the Ruby version seems to require intimate knowledge of its syntax.

> Is this what idiomatic Python has become?

What do you mean? Python has always been that way. "Explicit is better than implicit. [..] Readability counts." from the Zen of python.

> By contrast, here's the equivalent Ruby:

Which is awful to read. And of course you could write it similar short in python. But it is not the purpose of a documentation to write short, cryptic code.

That Ruby code is clever and concise, and terrible to read and extend