[Python-Dev] Improved evaluator added to ast module (original) (raw)

Georg Brandl g.brandl at gmx.net
Thu Oct 18 17:41:58 CEST 2012

On 10/18/2012 03:16 PM, Daniel Holth wrote:

On Thu, Oct 11, 2012 at 1:36 PM, Vinay Sajip <vinaysajip at yahoo.co.uk> wrote:

Daniel Holth <dholth 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 literaleval(). 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 literaleval 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

More information about the Python-Dev mailing list