[C++-sig] PyEval_EvalCode

Alan Baljeu alanbaljeu at yahoo.com
Wed Nov 12 15:29:37 CET 2008


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 <seefeld at sympatico.ca>
To: Development of Python/C++ integration <cplusplus-sig at 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 at 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/


More information about the Cplusplus-sig mailing list