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

[Mike Miller]

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