[Python-Dev] Compiler hints to control how f-strings are construed

[Barry Warsaw]

On Aug 17, 2015, at 01:36 PM, Guido van Rossum wrote:

>> 1. Barry wants the substitutions to look like $identifier and possibly
>> ${identifier}, and the PEP 498 proposal just uses {}.
>>
>> 2. There needs to be a way to identify interpolated strings and i18n
>> strings, and possibly combinations of those. This leads to PEP 501's i-
>> and iu- strings.
>>
>> 3. A way to enforce identifiers-only, instead of generalized expressions.
>
>In an off-list message to Barry and Nick I came up with the same three
>points. :-)
>
>I think #2 is the hard one (unless we adopt a solution like Yury just
>proposed where you can have an arbitrary identifier in front of a string
>literal).

I've been heads-down on other things for a little while, but trying to
re-engage on this thread.  One thing that occurs to me now regarding points #1
and #3 is that, if we had a way to signal to the compiler how we wanted
f-strings (to use a helpful shorthand) to be parsed, we could solve both
problems and make the feature more useful for i18n.

I'm thinking something along the lines of __future__ imports, which already
influence how code in a module is construed.  If we had a similar way to hint
that f-strings should be construed in a way other than the default, I could do
something like:

from __string__ import f_strings_as_i18n

at the top of my module, and that would slot in the parser for PEP 292 strings
and no-arbitrary expressions.  I'd be fine with that.

There are some downsides of course.  I wouldn't be able to mix my simpler,
i18n-based strings with the default full-featured PEP 498/501 strings in the
same module.  I can live with that.

I don't see something like a context manager being appropriate for that use
case because it's a run-time behavior, even if the syntax would look
convenient.

The hints inside the __string__ module wouldn't be extensible, except by
modifying Python's stdlib.  E.g. if you wanted $-strings but full expression
support, we'd have to write and distribute that with stdlib.  I'm also fine
with this because I think there aren't really *that* many different use
cases.

(There's still #2 but let's deal with that later.)

>> 4. We need a "safe substitution" mode for str.format_map_simple (from
>> above).

Again, a `from __string__` import could solve that, right?

Cheers,
-Barry