[Python-ideas] Draft PEP on string interpolation

[Paul Moore]

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

Paul.