<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 10, 2015 at 2:04 PM, Carl Meyer <span dir="ltr"><<a href="mailto:carl@oddbird.net" target="_blank">carl@oddbird.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 08/10/2015 02:49 PM, Eric V. Smith wrote:<br>
> On 08/10/2015 02:44 PM, Yury Selivanov wrote:<br>
>><br>
>><br>
>> On 2015-08-10 2:37 PM, Eric V. Smith wrote:<br>
>>>> Besides, any expression you have to calculate can go in a local that<br>
>>>> will get<br>
>>>>> interpolated. The same goes for any !r or other formatting<br>
>>>> modifiers. In an<br>
>>>>> i18n context, you want to stick to the simplest possible substitution<br>
>>>>> placeholders.<br>
>>> This is why I think PEP-498 isn't the solution for i18n. I'd really like<br>
>>> to be able to say, in a debugging context:<br>
>>><br>
>>> print('a:{self.a} b:{self.b} c:{self.c} d:{self.d}')<br>
>>><br>
>>> without having to create locals to hold these 4 values.<br>
>><br>
>> Why can't we restrict expressions in f-strings to<br>
>> attribute/item getters?<br>
>><br>
>> I.e. allow f'{foo.bar.baz}' and f'{self.foo["bar"]}' but<br>
>> disallow f'{foo.bar(baz=something)}'<br>
><br>
> It's possible. But my point is that Barry doesn't even want<br>
> attribute/item getters for an i18n solution, and I'm not willing to<br>
> restrict it that much.<br>
<br>
</span>I don't think attribute access and item access are on the same level<br>
here. In terms of readability of the resulting string literal, it would<br>
be reasonable to allow attribute access but disallow item access. And I<br>
think attribute access is reasonable to allow in the context of an i18n<br>
solution as well (but item access is not). Item access is much harder to<br>
read and easier for translators to mess up because of all the extra<br>
punctuation (and the not-obvious-to-a-non-programmer distinction between<br>
a literal or variable key).<br>
<br>
There's also the solution used by the Django and Jinja templating<br>
languages, where dot-notation can mean either attribute access<br>
(preferentially) or item access with literal key (as fallback). That<br>
manages to achieve both a high level of readability of the<br>
literal/template, and a high level of flexibility for the context<br>
provider (who may find it easier to provide a dictionary than an<br>
object), but may fail the "too different from Python" test.<br></blockquote><div><br></div><div>References for (these) PEPs:</div><div><br></div><div>One advantage of Python HAVING required</div><div>explicit template format interpolation string contexts</div><div>is that to do string language formatting correctly</div><div>(e.g. *for anything other than printing strings to console*</div><div>or with formats with defined field/record boundary delimiters</div><div> (which, even then, may contain shell control escape codes))</div><div>we've had to write and use external modules</div><div>which are specific to the output domain (JSON, HTML, CSS, SQL, SPARQL, CSS, [...]).</div><div><br></div><div>There are a number of posts about operator syntax, which IMHO, regardless, it's not convenient enough to lose this distinctive 'security' feature (explicit variable bindings for string interpolation) of Python as a scripting language as compared to e.g. Perl, Ruby.</div><div><br></div><div>Jinja2 reimplements and extends Django template syntax -{% for %}{{variable_or_expr | filtercallable}}-{% endfor %}</div><div><br></div><div>* Jinja2 supports configurable operators {{ can instead be !! or !{ or ${ or ??</div><div>* Because it is a compilable function composition, Jinja2 supports extensions:</div><div><a href="https://github.com/mitsuhiko/jinja2/blob/master/tests/test_ext.py">https://github.com/mitsuhiko/jinja2/blob/master/tests/test_ext.py</a></div><div>* Jinja2 supports {% trans %}, _(''), and gettext("") babel-style i18n</div><div> <a href="http://jinja.pocoo.org/docs/dev/templates/#i18n">http://jinja.pocoo.org/docs/dev/templates/#i18n</a></div><div><div>* Jinja2 supports autoescaping:</div><div> <a href="http://jinja.pocoo.org/docs/dev/api/#autoescaping">http://jinja.pocoo.org/docs/dev/api/#autoescaping</a></div></div><div><br></div><div>(e.g. 'jinja2.ext.autoescape' AutoEscapeExtension [ScopedEvalContextModifier])<br></div><div><a href="https://github.com/mitsuhiko/jinja2/blob/master/jinja2/ext.py#L434">https://github.com/mitsuhiko/jinja2/blob/master/jinja2/ext.py#L434</a><br></div><div><br></div><div>* preprocessors and things are then just jinja2.ext.Extension s.</div><div><br></div><div>* Jinja2 accepts an explicit context </div><div> (where merge(globals, locals, kwargs) just feels wrong because it is,</div><div> ... [ ] lookup(**kwargs), lngb(**kwargs)) (salt pillar merges))</div><div><br></div><div> ~ collections.abc.MutableMapping:</div><div> <a href="https://docs.python.org/3/library/collections.abc.html#collections.abc.MutableMapping">https://docs.python.org/3/library/collections.abc.html#collections.abc.MutableMapping</a></div><div><br></div><div>* Jinja2 marks strings with MarkupSafe (in order to prevent e.g. multiple escaping, lack of escaping)</div><div><br></div><div> <a href="https://pypi.python.org/pypi/MarkupSafe">https://pypi.python.org/pypi/MarkupSafe</a></div><div><br></div><div>f-strings would make it too easy for me to do the wrong thing;</div><div>which other language don't prevent (this does occur often [CWE Top 25 2011]),</div><div>and I regard this as a current feature of Python.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Carl<br>
<br>
</font></span><br>_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com</a><br>
<br></blockquote></div><br></div></div>