Boost logo

Boost Users :

From: David Abrahams (dave_at_[hidden])
Date: 2006-01-16 11:27:55

"Drumheller, Michael" <michael.drumheller_at_[hidden]> writes:

> (Sorry for the lateness of this response to the notes of Dave
> Abrahams, Tony Kirke, Stefan Seefeld & Roman Yakovenko.)
> I asked whether anyone out there gets anything done using Boost.Python
> *without* using Pyste or pyplusplus, and I said
>>> It does not seem like a practical thing to do--but maybe I'm
>>> missing something...?
> Dave replied:
>>> Why do you say that?
> Similarly, Stefan replied:
>>> I have been using boost.python for a number of projects but I never
>>> used pyste for any of them. What's wrong with that ? What do you
>>> think *I* am missing ?
> (By the way, Stefan: Does your above remark mean you have not tried
> Pyste, or you tried it and decided to use Boost.Python directly?)
> To answer your questions: Maybe I *would* just be using Boost.Python
> directly if I had spent a more time getting used to it at the
> beginning. But I found that getting even the simplest class
> hierarchies with virtual functions to work was an error-prone pain in
> the rear, not to mention a lot of typing. I discovered Pyste at the
> same time, and tried it, and looked at its output and said, "Wow, I'm
> glad I didn't have to write all that myself. Who has time for that?"
> I mean, Pyste's output is by definition a mechanical transformation of
> my C++ header files--why would I want to perform such a transformation
> by hand? That's how I got hooked on Pyste.

Agreed; once you start wrapping lots of virtual functions, having a
code generator is a big help.

> It occurs to me that maybe the reason you do not seem bothered by
> writing Boost.Python code manually is that you're doing it
> "minimally," i.e., you're exposing that part (and only that part) of
> your C++ interface that really needs to be exposed at the Python
> level. I think I need to revisit my code with this in mind, and I
> will do that. And/or maybe I can/should just use Pyste as a
> "bootstrap" mechanism--to generate the *first version* of my
> Boost.python files, but maintain them manually thereafter. Roman
> indicates, with this message,
> <<>>,
> that this is what a lot of people do, but I'm not sure it has really
> been substantiated.

It's true, lots of people do that. But IIRC pyste still generates
old-style polymorphism, which is inferior in many ways to the approach
currently described in the tutorial and which, IIUC, pyplusplus also

> Of course, there is at least one excellent reason for writing
> Boost.Python wrappers by hand: The longer your tool chain, the more
> complicated your life. A longer tool chain (i.e., a tool chain with
> Pyste *and* GCCXML in it) makes it harder for me to sell the hybrid
> Python/C++ approach to my organization--or even to myself.

Yes, that's one important argument for using a DSEL (Domain Specific
**Embedded** Language) like Boost.Python. discusses this at length.

> It is not clear to me what the right balance is between automatic
> Boost.Python code generation & tool-chain complexity. I'm sure it is
> project-dependent.


> I suppose my main suggestion is that the Boost
> documentation might provide more guidance in making this
> trade-off. (There is a link to Pyste and that's it. There is no
> discussion about trade-off or how to address it.)

Good point. But as long as pyste is using old-style polymorphism I
think I don't really want to recommend that people use it. And as
long as pyplusplus doesn't get its documentation act together, I don't
really want to recommend that people use _it_, either. So I don't
know what to do with all this software that's -- to some degree --
only partially baked.

Dave Abrahams
Boost Consulting

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at