[Python-ideas] String interpolation for all literal strings

[Oscar Benjamin]

On 5 August 2015 at 19:56, Eric V. Smith <eric at trueblade.com> wrote:
>
> In the "Briefer string format" thread, Guido suggested [1] in passing
> that it would have been nice if all literal strings had always supported
> string interpolation.
>
> I've come around to this idea as well, and I'm going to propose it for
> inclusion in 3.6. Once I'm done with my f-string PEP, I'll consider
> either modifying it or creating a new (and very similar) PEP.
>
> The concept would be that all strings are scanned for \{ and } pairs. If
> any are found, then they'd be interpreted in the same was as the other
> discussion on "f-strings". That is, the expression between the \{ and }
> would be extracted and searched for conversion characters and format
> specifiers. The expression would be evaluated, converted if needed, have
> its __format__ method called, and the resulting string inserted back in
> to the original string.

I strongly dislike this idea. One of the things I like about Python is
the fact that a string literal is just a string literal. I don't want
to have to scan through a large string and try to work out if it
really is just a literal or a dynamic context-dependent expression. I
would hold this objection if the proposal was a limited form of
variable interpolation (akin to .format) but if any string literal can
embed arbitrary expressions than I *really* don't like that idea.

It would be better if strings that have this magic behaviour are at
least explicitly marked. The already proposed f-prefix requires a
single character to prefix the string but that single character would
communicate quite a lot when looking at unfamiliar code. It's already
necessary to check for prefixes at the beginning of a string literal
but it's not necessary to read the whole (potentially large) thing in
order to understand how it interacts with the surrounding code.

I don't want to have to teach my students about this when explaining
how strings work in Python. I was already thinking that I would just
leave f-strings out of my introductory programming course because
they're redundant and so jarring against the way that Python code
normally looks (this kind of thing is not helpful to people who are
just learning about statements, expressions, scope, execution etc). I
also don't want to have to read/debug code that is embedded in string
literals:

message = '''\
...
x = \{__import__('sys').exit()}
...
'''

> Because strings containing \{ are currently valid, we'd have to
> introduce this feature with a __future__ import statement. How we
> transition to having this be the default interpretation of strings is up
> in the air.

This is a significant compatibility break. I don't see any benefit to
justify it. Why is

    print('x = \{x}, y = \{y}')

better than

    print(f'x = {x}, y = {y}')

and even if you do prefer the former is it really worth breaking existing code?

> Guido privately suggested that it might be nice to also support the 'f'
> modifier on strings, to give the identical behavior. This way, you could
> start using the feature without requiring the __future__ import. While
> I'm not crazy about having two ways to achieve the same thing, I do
> think it might be nice to support interpolated strings without requiring
> the __future__ import.

What would be the point? If both are available then I would just
always use the f-string since I prefer local explicitness over the
global effect of a __future__ import. Or is there a plan to introduce
the f-prefix and then deprecate it in the even more distant future
when all strings behave that way?

--
Oscar