Yet another attempt at a safe eval() call

Chris Angelico rosuav at gmail.com
Fri Jan 4 17:51:23 CET 2013


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. Can you demand that open parenthesis be
preceded by an operator (or beginning of line)? For instance:

(1+2)*3+4 # Valid
1+2*(3+4) # Valid
1+2(3+4) # Invalid, this will attempt to call 2

You could explain it as a protection against mistaken use of algebraic
notation (in which the last two expressions have the same meaning and
evaluate to 15). Or, alternatively, you could simply insert the
asterisk yourself, though that could potentially be VERY confusing.

Without parentheses, your users will be forced to store intermediate
results in variables, which gets tiresome fast.

discriminant = b*b-4*a*c
denominator = 2*a
# Okay, this expression demands a square rooting, but let's pretend that's done.
sol1 = -b+discriminant
sol2 = -b-discrminant
sol1 = sol1/denominator
sol2 /= denominator # if they know about augmented assignment

You can probably recognize the formula I'm working with there, but
it's far less obvious and involves six separate statements rather than
two. And this is a fairly simple formula. It'll get a lot worse in
production.

ChrisA



More information about the Python-list mailing list