eval, exec and execfile dilemma
gandalf at shopzeus.com
Sun Jul 31 06:21:11 EDT 2011
>> 100 functions/second
>> installed to global namespace doesn't sound well.
> What on earth are you doing needing to use exec to create hundreds of
> Have you considered not using exec at all, and using a good old-fashioned
> factory function and closures?
> def factory(x):
> def inner(param):
> return param + x
> return inner
> plusone = factory(1)
> plustwo = factory(2)
> I'm betting that this will be much faster than exec, and much more readable.
I'm working on a program that creates pivot tables from
multi-dimensional databases. The user is able to give expressions in a
tiny language. These expressions are then converted to Python source
code, and compiled into functions.
The generated function is called with several different numpy arrays. In
most cases, there are only a few functions are created (e.g. when the
user changes the expression) and they are called many times. But
sometimes (for example, when creating charts from the data) I have to
generate a separate function for every fact set in the database. When
there are many data series with lots of data in the graph, some 100
functions needs to be generated very fast.
This cannot be done using factory functions, because the function code
depends on the user's expression. It COULD be done in a different way:
parsing the user's expression into an abstract syntax tree and then
provide methods in the AST to evaluate itself. But this approach would
use too many python method calls. By generating the function source
code, I can reduce the number of Python method calls needed from several
thousand to ten or so. In most cases, the user will enter an expression
that will produce a lambda function (eval+lambda). But with more
elaborate expressions, I cannot efficiently convert it to a lambda
Of course the user can always write the expression in pure Python source
code, but there are obvious problems with that...
More information about the Python-list