[C++-sig] PyCode_New and new.code() functions

anders langlands anderslanglands at gmail.com
Mon Sep 11 16:17:07 CEST 2006


Thanks stefan, that does indeed look pretty simple!

However, is there any way I can do this with having my own interpreter?

The problem I am trying to solve is this:

I have a large class library I want to bind to python. Everything in the
library (Derived) is derived ultimately from a single class, Base. Now I
have functions to serialize and deserialize objects to disk. The deserialize
function returns a Derived object as a Base*. When this Base* is passed back
to python, python doesn't know that it's actually a Derived object, and it
would be nice if it did. I basically want to be able to automatically cast
the Base object to whichever flavour of Derived object it actually is in
python.

No all my objects support the functions typeId() and typename() to get
information about what they are. So the solution I've come up with is this.
I just store a big dict or list in the globals which maps typeId's to
functions. These functions do the conversion of the base type to the derived
type and the whole thing looks something like this:

-------

def castDerivedTypeA( obj ):
        return DerivedTypeA( obj )

def castDerivedTypeB( obj ):
        return DerivedTypeB( obj )

_globalCastsDict = {
        DerivedTypeATypeId : castDerivedTypeA,
        DerivedTypeBTypeId : castDerivedTypeB,
}

def cast( obj ):
        return _globalCastsDict[ obj.typeId() ]( obj )

--------

Now obviously with a large class library it's going to be tedious and
error-prone to maintain all those functions etc by hand. So what I'd like is
to automatically generate the code in C++ at binding time. What I'd like is
to do something like:

BOOST_PYTHON_MODULE( _mymodule )
{
        class_<DerivedA,bases<Base> >( "DerivedA" )
        ;

        exec( "code for castDerivedA function",
current_interpreter.globals(), current_interpreter.locals() );
}

Is it possible to get the globals from the currently running interpreter
without actually writing the interpreter executable yourself? I realise I
could just write my own interpreter and all would be fine and dandy, but I'd
like this to be able to work even if I'm running in the standard python
interrpreter

A




On 9/11/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> anders langlands wrote:
>
> > boost::python::exec sounds like exactly what I want... but I can find no
> > documentation for this either, do you have I link? Nor can I find it in
> any
> > of the boost::python headers. we're using boost 1_33_1 here at the
> moment.
>
> Ah, well, I added it after the 1_33_1 release. It will be included in the
> 1_34
> release (in case that is of any help).
>
> However, the implementation is really simple, so you may as well include
> the
> code directory:
>
>
> namespace boost
> {
> namespace python
> {
> object exec(str string, object global, object local)
> {
>   // should be 'char const *' but older python versions don't use 'const'
> yet.
>   char *s = python::extract<char *>(string);
>   PyObject* result = PyRun_String(s, Py_file_input, global.ptr(),
> local.ptr());
>   if (!result) throw_error_already_set();
>   return object(detail::new_reference(result));
> }
> }
> }
>
> This executes 'string' in the context of 'global' and 'local'. The latter
> two
> are (potentially empty) dictionaries. Once execution has successfully
> terminated,
> 'global' will contain whatever objects 'string' injected into them such as
> type definitions
> and other objects. You can then extract these from 'global' and call them
> from C++.
> See for example
>
> http://boost.cvs.sourceforge.net/*checkout*/boost/boost/libs/python/test/exec.cpp?revision=1.5.2.1
>
> HTH,
>                 Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20060911/5029b07c/attachment.htm>


More information about the Cplusplus-sig mailing list