[Python-ideas] extensible template strings

[Yury Selivanov]

On 2015-08-19 8:49 PM, Eric V. Smith wrote:
> On 8/19/2015 8:28 PM, Steven D'Aprano wrote:
>> On Wed, Aug 19, 2015 at 08:15:05PM -0400, Eric V. Smith wrote:
>>> On 8/19/2015 7:43 PM, Guido van Rossum wrote:
>>>> How important is it really to *hide* the fact that this involves a
>>>> function call?
>>> The only reason PEPs 498 and 501, and by extension Yuri's proposal, have
>>> any difference over a function call is the ability to evaluate the
>>> embedded expressions in the local context, before the function is
>>> called.
>> Isn't that exactly what a normal function call does?
>>
>> func(expr)
>>
>> evaluates expr in the local context before the function is called.
> Yes. But you couldn't write:
>
> sql('select {columns} from {table}')
>
> And have it get columns and table from where the sql function were
> called. See the discussions preceding PEP 498.
>
>> Yuri linked to the Javascript reference for this feature, which
>> explicitly warns that "template strings" are a security risk:
>>
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/template_strings
>>
>> It looks to me that the sql'...' version above is trivially vunerable to
>> code injection attacks.
> The sql function could do all of the correct escaping. What's generally
> to be avoided is building the strings without escaping.

Exactly.

I'm not sure I buy the security risk argument -- in fact it is
safer to use sql'...' than to write something like

    db.query('select  ... where {}'.format(request.get['id']))

>
> And there's no particular reason that the sql function would even return
> a string: it might return an object that generated and stored the string
> "select ? from ?" and stored the values for columns and names (dbapi
> qmark style).

Right, it should be able to return anything.

Yury