[Python-ideas] Draft PEP on string interpolation

Paul Moore p.f.moore at gmail.com
Tue Aug 25 23:19:48 CEST 2015

On 25 August 2015 at 20:06, Mike Miller <python-ideas at mgmiller.net> wrote:
> This means numerous callers using e-strings won't have to do explicit
> escaping, only a handful of callee libraries will--which is common with
> database apis, for example.  What is easiest to type is now safe as well::
>     sensitive_func_that_escapes_input(e'user input: {input}')  # sleep easy

OK. The issue here is that if the user mistakenly calls a function
that *doesn't* escape its input, expecting that it will, there will be
a silent vulnerability. The problem isn't what I thought it was, using
the wriong type of string, it's more about using the wrong function.

Of course, having two functions one of which is e-string aware and
safe, and one of which isn't, and is unsafe, is a pretty bad API. Or
is it? Developers will for quite a long time have to deal with
providing compatibility for versions of Python with and without
e-strings. Consider pyinvoke - invoke.run() runs shell commands, much
like os.system. Suppose version X of pyinvoke adds e-string support.
If I write a program using e-strings and invoke.run, it's safe for
people with pyinvoke version X installed, but unsafe if my users have
version X-1 installed. That's a pretty nasty bug.

I honestly have no idea how significant this risk is. But it's
something that should be considered when claiming that the proposal
makes it "hard to do the wrong thing".


More information about the Python-ideas mailing list