PEP 750: Tag Strings for Writing Domain-Specific Languages

Yikes. Don't get me wrong, I totally understand the reasoning why this would be useful (though I violently disagree with the idea of deferring the evaluation of the contained expressions), but it's also so very kitchensinky and adds so little over just calling a function (which doesn't require a 20-page explainer, as everyone already knows how function calls work). It also promotes using what looks like string interpolation (and what might be string interpolation, you can't tell at the "call site") for things which we know string interpolation is the wrong tool. The API also seems really, I dunno, weird to me. The string is split around interpolations and verbatim portions result in one argument, which is "string-like", while interpolations become four-tuple-like (one of which is a lambda, which you call to perform the deferred interpolation). This seems really awkward to me for building stuff like the suggested use cases of XML/HTML or SQL templating.

Also the scoping rules of this are a special case which doesn't appear in regular Python code so far: "The use of annotation scope means it’s not possible to fully desugar interpolations into Python code. Instead it’s as if one is writing interpolation_lambda: tag, not lambda: tag, where a hypothetical interpolation_lambda keyword variant uses annotation scope instead of the standard function scope." -- i.e. it's "as if you wrapped all interpolation expressions in a lambda: , except it uses different scoping rules".

It seems the purpose of this proposal is to have a way to essentially have custom string interpolation. I don't think that's necessarily a bad idea on its own, but this syntax feels out of place to me.

Instead, why not add a single new string prefix, like "l" for "lazy"? So, f"hello {name}" would immediately format it while l"hello {name}" would produce an object which contains a template and the captured variables. Then their example would be called like: greet(l"hello {name}").

This like a bad idea on the first glance? Maybe I don't get the whole pitch here?

It just doesn't seem worth it to define a whole new thing just to abstract over a format() function call. The laziness might be interesting, but I feel like "lazy strings" might be all that's needed here. Laziness and validation (or custom string formatting logic) are separate concerns and should be separated.

Looks good. Would have been nice if they included a way to express type checking of the format_spec. That’s going to be an unnecessary source of runtime errors.

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.