Re: Pyste/Pyplusplus/Boost documentation problems

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Pyste/Pyplusplus/Boost documentation problems

Drumheller, Michael
(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.

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.

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.

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.)

Thanks,

Michael

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Pyste/Pyplusplus/Boost documentation problems

David Abrahams
"Drumheller, Michael" <[hidden email]> 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

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users