On Sat, Jan 5, 2013 at 4:14 AM, Grant Edwards <invalid@invalid.invalid> wrote: > On 2013-01-04, Chris Angelico <ros...@gmail.com> wrote: >> On Sat, Jan 5, 2013 at 3:38 AM, Grant Edwards <invalid@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 -- http://mail.python.org/mailman/listinfo/python-list
