eval, exec and execfile dilemma

Laszlo Nagy 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
> functions??????
> 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 mailing list