On 10/18/2012 03:16 PM, Daniel Holth wrote: > On Thu, Oct 11, 2012 at 1:36 PM, Vinay Sajip <vinay_sa...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
