From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-07-27 12:20:04
----- Original Message -----
Sent: Friday, July 27, 2001 9:57 AM
Subject: [boost] Boost::python: class conversions revisited
> I'm still trying to find the best solution for the problem I already
> mentioned in http://groups.yahoo.com/group/boost/message/14803
> So I set out to write a conversion function of my own:
> PyObject* to_python(const Expression& e)
> return to_python(Term(e));
> I was actually afraid that this would convert all my Expressions
> straight to Terms, which is also not really what I want, but instead
> this code changes nothing to the previous behaviour.
I'm not sure why, but it seems to me that the approach is backwards. What
you probably want is to convert Expressions to Terms in
from_python(PyObject*, boost::python::type<Term>). Otherwise, you do stand
to lose the identity of Expression as a separate type.
> So, my question: can I add some code, either to my own code or to the
> Boost library, to get the behaviour I want?
You might try modifying or specializing class_registry<Term> so that
try_class_conversions takes care of it. This question might be better
answered by Ullrich Koethe, who wrote that code, though.
> I started looking through the source, but with all these templates,
> the flow of control is not really immediately obvious. Specifically,
> when and from where is gen_extclass.py called?
Almost never; it's just done by a developer when extension_class.cpp needs
modification. We modify gen_extclass.py instead.
> It seems to act like a
> preprocessor, but due to my lack of understanding of the BPL big
> picture, I currently don't see where it fits in.
It's /like/ a preprocessor. Think of it as a code generator. There are many
places where boilerplate code needs to be extended (see
boost/python/callback.hpp), so I have some Python scripts to do it. If I
were starting over I'd probably use the new boost preprocessor library.
Maybe not, though - preprocessor-heavy code can be hard to debug.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk