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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
