[Tutor] What Eval() Hath Men Wrought
robinst at MIT.EDU
Tue Jun 22 12:22:47 EDT 2004
I'm really glad to see discussion about eval(), since I was wondering what
the alternatives are to it. I'm brand new to python, and my best skills
are probably in C++ & Matlab.
Some of us want to write an optimization toolbox for python, similar to
the one in Matlab. Many of the toolbox functions will require functions
For example, we'll want to write a function to minimize the return value
of another function by varying the latter function's vector argument.
The C way to do it is to pass in a pointer to a function. This is good
because C nicely checks that the function 1) is actually a function 2)
takes the right arguments 3) returns the right type. The Matlab way to do
it is to pass a string that contains the function name, and to use the
Matlab feval function, which is similar to the Python eval but nicer since
you don't have to construct the whole string yourself, but instead can use
the form feval('function_name',argument). This works but is bad because
you get weird errors if the function name is wrong, or if the function
takes an unexpected kind of argument or returns an unexpected type.
What is the right way to do this in Python? Where can I learn how to do
On Fri, 18 Jun 2004, Magnus [iso-8859-1] Lyck=E5 wrote:
> At 18:34 2004-06-17 -0800, Tim Johnson wrote:
> ><gr>Couldn't resist that subject since I hear
> >the eval (the built-in) is 'evil'. </gr>
> >I've been looking through the Python Cookbook, and
> >there's an example at
> > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66018
> >look for
> > class Eval:
> > # ...... code following
> >This appears to be a handy class, but given the concerns about
> >built-in function eval, I would welcome comments and caveats.
> As I see it, there are some problems with eval()
> - It's slow, e.g. eval('5') is about ten times slower than int('5').
> - It might cause unpredicted results unless you are certain about
> what you run eval on. This isn't really a problem if you only run
> eval on hardcoded strings in your source code as the Cookbook
> example does. In some programs eval could cause security problems.
> For instance, an attacker might be able to display passwords stored
> in program variables etc.
> - It makes it more difficult to analyse the code, for instance with
> some automatic tool such as PyChecker or PyLint. (Or manually for
> that matter.)
> - Debugging get's harder. You might hide syntax errors until runtime
> etc. I imagine tracebacks are less helpful too.
> Besides, I'm not really sure that
> print "%(text.capitalize())s %(number/9.0).1f rules!" % Eval()
> is better than
> print "% %.1f rules!" % (text.capitalize(), number/9.0)
> This is some kind of ASP syndrome, and it seems to me that most
> programmers seem to agree that mixing code in text as in ASP or
> as in the Eval example typically causes maintenance problems.
> Whether we're talking about web pages or something else, we'll
> often want to separate the maintenace of the text from the
> maintenance of the code. I often do things similar to:
> params =3D dict(capText=3Dtext.capitalize(), verNumber=3Dnumber/9.0)
> print "%(capText)s %(verNumber).1f rules!" % params()
> or even something like
> print "%(capText)s %(verNumber).1f rules!" % vars()
> but it might be even better to use a real templating system
> such as cheetah etc. See
> Eval might look neat, but I think you will end up missing
> the syntax coloring of your python statements if you put
> them in strings, and that it will turn out to be trickier
> to find bugs.
> Magnus Lycka (It's really Lyckå), magnus at thinkware.se
> Thinkware AB, Sweden, www.thinkware.se
> I code Python ~ The Agile Programming Language
> Tutor maillist - Tutor at python.org
More information about the Tutor