Alan Baljeu wrote:
My question probably derives from ignorance of the Python way. I kind of
assumed people would advocate defining classes and methods, and then calling
those methods. You apparently see things otherwise.
Not really. I just see it as an orthogonal problem to the question you
asked in your previous mail.
One thing I'm considering is to make one layer of abstraction, and define a
Python function which takes a dictionary and a script file name. I think this
level would make the code more instrumentable than with all the stuff in C++.
Again, without at last a little bit of context (what is your application
doing, and what part of that would you like to control via python
scripts) it's very hard to have a meaningful discussion. Also, I'm not
sure whether your question is really specific to 'eval', or whether you
also include 'exec' into this discussion (eval evaluates an expression
and returns the result, while exec runs code, not necessarily returning
anything).
It seems your question is all about the boundary / interface between the
(C++) application and the script that gets invoked: What should the
content of the dictionary be, and what is the script expected to do with
it ?
In the most trivial case such a script could simply store named values
(numbers, strings) into the dictionary, which then get evaluated
by the application. The script thus becomes a mere configuration file.
Alternatively, you can inject functions or even objects into the
dictionary, which the script is expected to interact with. How much
'Object-Orientedness' makes sense really depends on your needs, which
you haven't talked about yet.
Regards,
Stefan
--
...ich hab' noch einen Koffer in Berlin...
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
