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