Re: [Boost-users] Pyste/Pyplusplus/Boost documentation problems
(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
"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.
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
participants (2)
-
David Abrahams -
Drumheller, Michael