[Python-ideas] Draft PEP on string interpolation

[Guido van Rossum]

On Sat, Aug 22, 2015 at 1:36 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 23 August 2015 at 02:16, Guido van Rossum <guido at python.org> wrote:
> > On Sat, Aug 22, 2015 at 3:09 AM, Nick Coghlan <ncoghlan at gmail.com>
> wrote:
> >> (Similar to yield, it is proposed that interpolation expressions would
> >> require parentheses when embedded inside a larger expression)
> >
> >
> > 1. That's an entirely different proposal, you're just reusing the PEP
> > number.
>
> It's aiming to solve the same basic problem though, which is the
> aspect I consider most important when tackling a design question. The
> discussions following the posting of my first draft highlighted some
> real limitations of my original design both at a semantic level and at
> a motivational level, so I changed it in place rather than introducing
> yet another PEP on the same topic (Mike Miller's draft PEP was an
> excellent synthesis, but there's no way he could account for the fact
> that 501 was still only a first draft).
>

Yeah, it's not unheard of for PEP authors to pivot after listening to
feedback. :-)

OTOH this topic is rich enough that I have no problem spending a few more
PEP numbers on it. If Mike asks for a PEP number I am not going to withhold
it.


> > 2.  Have I died and gone to Perl?
>
> That's my question in relation to PEP 498 - it seems to introduce lots
> of line noise for people to learn to read for little to no benefit (my
> perspective is heavily influenced by the fact that most of the code I
> write myself these days consists of network API calls + logging
> messages + UI template rendering, with only very occasional direct
> calls to str.format that use anything more complicated than "{}" or
> "{!r}" as the substitution field).
>
> As a result, I'd be a lot more comfortable with PEP 498 if it had more
> examples of potential practical use cases, akin to the examples
> section from PEP 343 for context managers.
>

Since you accept "!r", you must be asking about the motivation for
including ":spec", right? That's inherited from PEP 3101. For myself, I
know that the most common use of format specs is to limit the number of
digits printed for floating point numbers, e.g.

  t0 = time.time()
  chop_onions(n)
  t1 = time.time()
  print("Chopped %d onions in %.3f seconds." % (n, t1-t0))

Or, using PEP 3101,

  print("Chopped {} onions in {:.3f} seconds.".format(n, t1-t0))

Using the PEP 498 I can write this as

  print("Chopped {n} onions in {t1-t0:.3f} seconds.")

But in PEP 498 without :spec, I'd have to find some other way of formatting
t1-t0, and none of the alternatives look pretty. (Anything that requires
introducing a temporary variable feels particularly ugly to me.)


> While the second draft of PEP 501 is even more line-noisy than PEP 498
> due to the use of both "!" and "$", it at least generalises the
> underlying semantics of compiler-assisted interpolation to apply to
> additional use cases like logging, i18n (including compatibility
> with Mozilla's l20n syntax), safe SQL interpolation, safe shell
> command interpolation, HTML template rendering, etc.
>

That's perhaps a bit *too* ambitious. The claim of "safety" for PEP 498 is
simple -- it does not provide a way for a dynamically generated string to
access values in the current scope (and it does this by not supporting
dynamically generated strings). For most domains you mention, safety is
much more complex, and in fact mostly orthogonal -- code injection attacks
rely on the value of the interpolated variables, so PEP 498's "safety" does
not help at all. I18n safety may be the exception -- the scenario is an
untrustworthy translator who adds an interpolation that references a
variable whose content is deemed sensitive, perhaps a database key.


> For the third draft, I'll take another pass at the surface syntax - I
> like the currently proposed semantics, but agree the current spelling
> is overly sigil heavy.
>

Good luck.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150822/8de3c14b/attachment.html>