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.
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

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.


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

More information about the es-discuss mailing list