[Numpy-discussion] function name as parameter

Zachary Pincus zachary.pincus@yale....
Wed Oct 20 16:49:00 CDT 2010

> Hi Robert,
> so in a big data analysis framework, that is essentially written in C 
> ++,
> exposed to python with SWIG, plus dedicated python modules, the user
> performs an analysis choosing some given modules by name,as in :
> myOpt="foo"
> my_analyse.perform(use_optimizer=myOpt)
> The attribute use_optimizer is then checked to perform the right
> calls/instantiations of python but also C++ objects..... and the  
> actual
> crunching number is in the C++ part.
> But then I realize that I need to tweak this optimizer's state, and  
> the
> optimizer object is accessible from a library pyOpt that has been
> swigified from a C++ library.
> Then I access the object by calling optObject =
> eval("pyOpt.%s(some_args)"%myOpt)
> where myOpt would be "foo" in this particular analysis. This is  
> because
> what the attribute use_optimizer expects is also the object name in  
> the
> library, of course.
> It goes without saying that I could do :
> if myOpt=="foo":
>     optObject=pyOpt.foo(some_args)
> else:
>     ....
> and if you guys tell me it is way safer, I will do that instead of the
> use of eval that I liked because of the compactness.....

Well, optObject=getattr(pyOpt, myOpt) is a bit nicer and marginally  
more likely to return sane error messages than optObject=eval("pyOpt. 
%s"%myOpt). Then you could do result=optObject(some_args)...

But why not have the user just pass in the relevant optObject from the  
pyOpt namespace (or some restricted namespace that just has the  
relevant functions exposed)? E.g.
rather than

This lets users do introspection on the pyOpt namespace to see what  
functions they can choose from, which is rather friendlier in an  
interactive environment.


More information about the NumPy-Discussion mailing list