[Python-Dev] PEP-498: Literal String Formatting

[Wes Turner]

On Mon, Aug 10, 2015 at 2:04 PM, Carl Meyer <carl at oddbird.net> wrote:

> On 08/10/2015 02:49 PM, Eric V. Smith 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
> 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.MutableMapping

* 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 at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150810/d945b997/attachment-0001.html>