quasi-literal strawman

Mark Seaborn mseaborn at google.com
Mon Dec 21 07:48:38 PST 2009


On Tue, Dec 15, 2009 at 12:04 AM, Mike Samuel <mikesamuel at gmail.com> wrote:
> 2009/12/14 Ash Berlin <ash_js at firemirror.com>:
>
> > If you haven't yet read http://www.python.org/dev/peps/pep-3101/ (Advanced String Formatting) I
> > suggest you do - its well worth a read and feels like a possible very javascripty solution.
>
> I have not read it.  Thanks for the link.  It has a good summary of
> alternate syntaxes and establishes a point partway between positional
> and inline syntax.  It does include a bunch of format specifiers that
> I think incompatible with DSL schemes.

Python 2.6/3.0's new format() method lets you put attribute accesses
inline in the format string, e.g.
  "<em>{0.text}</em>".format(obj)
This is problematic for secure subsets of Python such as CapPython
that try to restrict attribute access [1].  There might be similar
problems for secure subsets of ES if something like Python 3.0's
scheme were adopted in ES.

Apparently the Python developers weren't aware of quasi-literals -- or
at least quasi-literals weren't proposed -- so they weren't
considered.

It seems to me that if you really want attribute accesses inline in
the format string, it's better to have these attribute accesses as
real expressions -- as quasi-literals allow -- rather than inventing a
new mini-language for them as Python 3.0 format strings did.

Cheers,
Mark

[1] http://lackingrhoticity.blogspot.com/2008/09/attribute-access-in-format-strings-in.html


More information about the es-discuss mailing list