[Python-Dev] Critique of PEP 502 (String Interpolation Redux) (original) (raw)

Mike Miller python-ideas at mgmiller.net
Sat Sep 5 19🔞20 CEST 2015

On 09/04/2015 08:15 PM, Guido van Rossum wrote:

The text of the PEP has too much on motivation and rationale: maybe that would be suitable for an informative PEP. The proposal itself is under-specified. But the real weakness cannot be fixed by improving the text: it is in the key…

I'm planning on writing an improved version, but haven't the time to get to it this past week; huge project at work. (Though it may not matter at this point as the last sentence indicates.)

Since another thread on the list just started about whether to allow arbitrary expressions, I think it is important to have a good explanation of that for those that might disagree at first, a place to send them. That was easier for me to write than making interpreter improvements, which explains the current state of PEP 502 well... fair enough.

This is initially likable: to recipients who don't know about e-strings they behave just like regular strings; but recipients who do know about them can extract the template and the values to be interpolated and use these to build an alternative string, e.g. to be used as a translation.

However, in order to fulfill the former requirement, the type must inherit from str (it's one of those built-in types for which duck typing doesn't always work). And at the same time this is a real problem, because it's too easy to..

Yes, was aiming to "split the difference" and produce a helpful object that could alleviate various concerns. The design is somewhat successful at that. However, while we could mitigate "losing the object" with docs and magic-methods, the end-result is still less compelling than I had hoped. The exercise was helpful in that regard.

There is something quite nice about the simplicity of PEP 498 for the developer. It can also be explained to critics as just "syntactic sugar over existing str.format," which is compelling. Though, can we do any cherry picking from these PEPs?

While the 498 implementation is great, I'd argue that the 502 expression-string nomenclature is a bit better. The terminology is not heavily used for strings in the stdlib (as format and template are), the e/expression name highlights the difference in capability, and in conversations doesn't remind one of the f-word, haha.

-Mike

More information about the Python-Dev mailing list