Showing content from http://mail.python.org/pipermail/python-dev/attachments/20150817/da27f5ee/attachment.html below:
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 17, 2015 at 1:26 PM, Eric V. Smith <span dir="ltr"><<a href="mailto:eric@trueblade.com" target="_blank">eric@trueblade.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[...]<br>
I think it would be possible to create a version of this that works for<br>
both i18n and regular interpolation. I think the open issues are:<br>
<br>
1. Barry wants the substitutions to look like $identifier and possibly<br>
${identifier}, and the PEP 498 proposal just uses {}.<br>
<br>
2. There needs to be a way to identify interpolated strings and i18n<br>
strings, and possibly combinations of those. This leads to PEP 501's i-<br>
and iu- strings.<br>
<br>
3. A way to enforce identifiers-only, instead of generalized expressions.<br></blockquote><div><br></div><div>In an off-list message to Barry and Nick I came up with the same three points. :-)<br><br></div><div>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).<br></div><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4. We need a "safe substitution" mode for str.format_map_simple (from<br>
above).<br>
<br>
#1 is just a matter of preference: there's no technical reason to prefer<br>
{} over $ or ${}. We can make any decision here. I prefer {} because<br>
it's the same as str.format.<br>
<br>
#2 needs to be decided in concert with the tooling needed to extract the<br>
strings from the source code. The particular prefixes are up for debate.<br>
I'm not a big fan of using "u" to have a meaning different from it's<br>
current "do nothing" interpretation in 3.5. But really any prefixes will<br>
do, if we decide to use string prefixes. I think that's the question: do<br>
we want to distinguish among these cases using string prefixes or<br>
combinations thereof?<br>
<br>
#3 is doable, either at runtime or in the tooling that does the string<br>
extraction.<br>
<br>
#4 is simple, as long as we always turn it on for the localized strings.<br>
<br>
Personally I can go either way on including i18n. But I agree it's<br>
beginning to sound like i18n is just too complicated for PEP 498, and I<br>
think PEP 501 is already too complicated. I'd like to make a decision on<br>
this one way or the other, so we can move forward.<br></blockquote><div><br></div><div>What's the rush? There's plenty of time before Python 3.6.<br></div><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>Â Â Â [...]<br>
>Â Â Â > The understanding here is that there are these new types of tokens:<br>
>Â Â Â > F_STRING_OPEN for f'...{, F_STRING_MIDDLE for }...{, F_STRING_END for<br>
>Â Â Â > }...', and I suppose we also need F_STRING_OPEN_CLOSE for f'...' (i.e.<br>
>Â Â Â > not containing any substitutions). These token types can then be used in<br>
>Â Â Â > the grammar. (A complication would be different kinds of string quotes;<br>
>Â Â Â > I propose to handle that in the lexer, otherwise the number of<br>
>Â Â Â > open/close token types would balloon out of proportions.)<br>
><br>
>Â Â Â This would save a few hundred lines of C code. But a quick glance at the<br>
>Â Â Â lexer and I can't see how to make the opening quotes agree with the<br>
>Â Â Â closing quotes.<br>
><br>
><br>
> The lexer would have to develop another stack for this purpose.<br>
<br>
I'll give it some thought.<br>
<span class="HOEnZb"><font color="#888888"><br>
Eric.<br>
</font></span></blockquote></div><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4