[C++-sig] Boost.Python code generator

David Abrahams dave at boost-consulting.com
Sat Dec 7 02:13:26 CET 2002

Nicodemus <nicodemus at globalite.com.br> writes:

> David Abrahams wrote:
>>I'd like to encourage you to step back and think about the
>>implications of where this is going.
>> You're already getting very close to C++.
> Indeed... the more classes that I pass to the interface file, more I
> see that the entire process could be more automated.
>>  1. Can you support a model where the user just annotates an existing
>>     class declaration with comments, for people who are developing
>>     the C++ interface as well as publishing bindings?
> Pyste was originally written by my colleague, and it used this
> approach. We opted by a interface file in the new version because we
> find that this design is intrusive to the library that will be
> exported, especially with 3rd party libraries. But it is certainly a
> viable solution, so much that this form is already implemented, but
> supports only boost v1.
>>  2. Can you support a model where the user just says "export class
>>     X", and then describes the /differences/ from some default way of
>>     exposing all of X's public interface, perhaps using Pure Python?
> I think that this is a nice approach: export all methods using some
> default rule, and everything that should not follow this rule must be
> explicitly specified like so.
> The only thing (from the top of my head) that couldn't work in a
> automated fashion is functions that return a pointer, since the user
> must specify the call policy. For this cases, what do you think would
> be a good approach? A separate file, or embedded tags?

I'm trying to suggest a pure python syntax. So I mean something more

    import Pyste


       # wrap all of foo::bar in the default way

               # don't wrap the 'bump' or 'debump' members
               , exclude = ['bump', 'debump'])

           # rename the 'blossom' member as 'Blossom'
           .fun('blossom', rename = 'Blossom')

           # specify call policies for the 'create' member function
                policies = 'return_value_policy<manage_new_object>')

> The separate file would be nice in my opinion, but the more I think
> about it the more it looks like SWIG, and then the "reinventing the
> weel"-sense starts tingling.

Well, you're definitely in the same territory.

                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

More information about the Cplusplus-sig mailing list