[C++-sig] Need strategic advice designing Boost/Python program

[Stefan Seefeld]

Craig Finch wrote:
> Stefan,
> Thank you for your input.  To answer your questions:
> 
>> I'm not sure what you mean by 'implement a constructor'. Can you
>> elaborate ?
>> As a minor point, if you go this route, there is no need to use
>> extract<>
>> to access values, as within C++, you'll always deal with the (native)
>> C++
>> interface directly. extract<> is useful to pull out embedded C++
>> objects
>> from python (wrapper) objects, or to require an explicit conversion /
>> cast.
> 
> Let's say that I have created classes in C++ that represent the data
> needed for my program.  However, I want to build the methods in Python
> because they need to be modified easily.  I have gotten this approach
> to work for methods except for __init__.  If I try to add a Python
> constructor to the class, it can't access the data members of the C++
> class.  I don't want to write the constructor in C++ because it's
> potentially very complicated, defeating the purpose of writing methods
> in Python.  What do you suggest?

This, together with your point further down that you want to add python
methods that are only ever used inside python make it sound as if
a C++ base class derived from in python may be the best approach.
I don't understand what you mean by "I can't access the data members of
the C++ class". Of course, you have to expose them to python via accessors
(say, as 'properties'), but as soon as that is done you can easily derive
and extend that base class from within python.

> Also, thank you for your explanation of <extract>.  It seems like I
> will still need to use extract, because I want the Python interface to
> use arrays in a Python-like manner.  On Ralf's suggestion, I will look
> at  scitbx to see how he handles it.

I'm not sure I understand. extract<> is a C++ API, that has nothing to
do with a Python interface. The only context in which you may need extract<>
here is when talking to a Python object (such as an instance of the derived
Python class) from within C++, which, as you stated earlier, you won't.


> Correct--the methods I am building in Python should not need to be
> accessible to the C++ solvers.  So, if I have a C++ base class
> containing all the "core" data, I can then derive Python classes which
> add methods and "extra" data.  In this case, how do I access the "core"
> data from C++, since it is now a derived class?

The same IS-A relationship that you would expect from a pure C++ program
still holds in this hybrid setting. If you have exposed a C++ function
(or method) expecting a parent reference (or pointer), a child reference
(or pointer) will be accepted as well.

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...