Yet another attempt at a safe eval() call

[Chris Angelico]

On Sat, Jan 5, 2013 at 4:14 AM, Grant Edwards <invalid at invalid.invalid> wrote:
> On 2013-01-04, Chris Angelico <rosuav at gmail.com> wrote:
>> On Sat, Jan 5, 2013 at 3:38 AM, Grant Edwards <invalid at invalid.invalid> wrote:
>
>>> I've added equals, backslash, commas, square/curly brackets, colons
>>> and semicolons to the prohibited character list. I also reduced the
>>> maximum length to 60 characters.  It's unfortunate that parentheses
>>> are overloaded for both expression grouping and for function
>>> calling...
>>
>> I have to say that an expression evaluator that can't handle parens
>> for grouping is badly flawed.
>
> Indeed.  That's why I didn't disallow parens.
>
> What I was implying was that since you have to allow parens for
> grouping, there's no simple way to disallow function calls.

Yeah, and a safe evaluator that allows function calls is highly vulnerable.

>> Can you demand that open parenthesis be preceded by an operator (or
>> beginning of line)?
>
> Yes, but once you've parsed the expression to the point where you can
> enforce rules like that, you're probably most of the way to doing the
> "right" thing and evaluating the expression using ast or pyparsing or
> similar.
>
> Some might argue that repeated tweaking of and adding limitiations to
> a "safe eval" is just heading down that same road in a different car.
> They'd probably be right: in the end, it will probably have been less
> work to just do it with ast.  But it's still interesting to try. :)

Yep, have fun with it. As mentioned earlier, though, security isn't
all that critical; so in this case, chances are you can just leave
parens permitted and let function calls potentially happen.

ChrisA