On Aug 20, 2015 23:40, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
>
[...]
> myquery = i"SELECT $column FROM $table;"
> mycommand = i"cat $filename"
> mypage = i"<html><body>$content</body></html>"
>
> It's the opposite of the "interpolating untrusted strings that may
> contain aribtrary expressions" problem - what happens when the
> variables being *substituted* are untrusted? It's easy to say "don't
> do that", but if doing the right thing incurs all the repetition
> currently involved in calling str.format, we're going to see a *lot*
> of people doing the wrong thing. At that point, the JavaScript
> backticks-with-arbitrary-named-callable solution starts looking very
> attractive:
>
> myquery = sql`SELECT $column FROM $table;`
> mycommand = sh`cat $filename`
> mypage = html`<html><body>$content</body></html>`
Surely if using backticks we would drop the ugly prefix syntax and just make it a function call?
myquery = sql(`SELECT $column FROM $table;`)
etc., where `...` returns an object with the string and substitution info inside it.
I can certainly appreciate the argument that safe quoting for string interpolation deserves as much attention at the language level in 2015 as buffer overflow checking deserved back in the day.
Taking that problem seriously though is perhaps an argument against even having a trivial string version, because if it's legal then people will still write
do_sql("SELECT $column FROM $table;")
instead and the only way to get them to consistently use delayed (safe) evaluation would be to constantly educate and audit, which is the opposite of good design for security and exactly the problem we have now. Really what we want from this perspective is that it should be *harder* to get it wrong than to get it right.
Maybe simple no-quoting interpolation should be spelled
str(`hello $planet`)
(or substitute favorite prefix tag if allergic to backticks), so you have to explicitly specify a quoting syntax even if only to say that you want the null syntax.
Alternatively I guess it would be enough if interfaces like our hypothetical sql(...) simply refused to accept raw strings and required delayed interpolation objects only, even for static/constant queries. But I'm unconvinced that this would happen, given the number of preexisting APIs that already accept strings, and the need to continue supporting pre-3.6 versions of python.
-n