Re: [Boost-users] Pyste/Pyplusplus/Boost documentation problems

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,
> <<http://mail.python.org/pipermail/c++-sig/2006-January/010030.html>>,
> 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
uses.

> 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.
http://www.boost-consulting.com/mplbook 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.  

Absolutely.

> 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
www.boost-consulting.com