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. 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++.
Alan Baljeu
----- Original Message ----
From: Stefan Seefeld <[EMAIL PROTECTED]>
To: Development of Python/C++ integration <cplusplus-sig@python.org>
Sent: Tuesday, November 11, 2008 4:25:00 PM
Subject: Re: [C++-sig] PyEval_EvalCode
Alan Baljeu wrote:
> I was reading some legacy code we have here, and discovered an unexpected
> idiom. Starting from C++, we create a dictionary, store a few named
> constants in there, and then call PyEval_EvalCode passing in the dictionary.
> The code it calls is a bunch of python files generated from a CAD model, with
> no function definitions. It works of course. Question is, what do you think
> of this approach? What is a more typical idiom?
>
I don't quite understand the question. What I think of this approach depends a
lot on what you use it for. Typical for what ?
Having a C++ application run some python script that has access to some of the
application state (i.e., whatever you expose through the dictionary) is
certainly a fine way to make your application scriptable.
(FWIW, boost.python offers 'exec()' and 'eval()' for this.)
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
__________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!
http://www.flickr.com/gift/
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
