
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