[Python-Dev] Improved evaluator added to ast module

[Georg Brandl]

On 10/18/2012 03:16 PM, Daniel Holth wrote:
> On Thu, Oct 11, 2012 at 1:36 PM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
>> Daniel Holth <dholth <at> gmail.com> writes:
>>
>>> How does this compare to the markerlib approach? In markerlib you just
>>> make sure all the AST nodes are in a set of allowed nodes, currently
>>> (Compare, BoolOp, Attribute, Name, Load, Str, cmpop, boolop), and then
>>> use the normal eval(). Is one way more secure / fast / flexible than
>>> the other?
>>
>> I don't think performance is an issue, and the markerlib approach seems just
>> as reasonable as the one I've taken, except that it calls eval(), whereas my
>> approach doesn't. It boils down to what should be allowed in expressions, and
>> what shouldn't be.
>>
>> ISTM there is a space for a limited evaluator that's less limiting than
>> literal_eval(). I do realise that this type of sandboxing is not easy to achieve,
>> and I'm not aiming to advance the state of the art here - I just want to close
>> the issue in the best way I can.
> 
> I bet the literal_eval approach simply predates compile(ast) which is
> a Python 2.6 feature.

Nope. All of ast (in contrast to _ast) is new in 2.6.

> It is also probably slightly faster on CPython
> to avoid compile(ast) if you are only evaluating the code once.

Yes; if you inspect the nodes anyway you can just as well evaluate them
on the way.

Georg