[C++-sig] Boost.Python: few thoughts and questions...

[Roman Sulzhyk]

All:

First, want to say thank you for terrific work on boost.python - first
time I've touched it in a few years and am very impressed by version
2.0 and especially pyste. 

Played around with it for a couple days, and have some questions,
didn't find ready answers when skimming through archives, so I
apologize if they've been voiced before.

To give a bit of a background, I'm trying to reflect a third-party C++
API into Python, so am kind of stuck with class definitions, and am
trying to do as little work as possible hence leveraging pyste.

1. Virtual functions

The automatic overloading of virtual functions is great, however I see
situations where it would be nice to be able to disable it. For
example,  I'm trying to expose a derived class which has some virtual
members inherited from its sub-classes, yet I have no intention to
overload them in python and hence would like to save on the wrapper
code generation.

Also, when I'm exposing a class, I think it would be nice to expose all
of the virtual methods inherited from base classes, even if they're not
explicitly overloaded in the class itself - do you think that would be
useful functionality to add?

2. Virtual functions declaring exceptions

Basically, a simple construct like this

struct foo {};
                                                                       
        
struct World
{
  virtual const std::string &hello() throw (foo) { return msg; }
};

causes pyste generated code to choke, because the exception declaration
of the wrapper function is looser than the original one (gcc 3.2)

3. Specifying the set_policy() for virtual functions

It appears that the policy setting is ignored for virtual function
declarations.

Anyway, I've started playing around with it and worked around some of
these issues, updating pyste to take into account policy for virtual
functions. For the throw specifier problem, it appears that there is no
easy solution, as GCCXML does not generate throw specifier data as far
as I can tell, requiring changes to gccxml for full solution.

I've also added an 'unvirtual' function to pyste, kind of like
'exclude', which allows a user to specify that a function should be
treated like a regular rather than virtual method when creating a
reflection - that works around the 'looser throw specifier' problem
I've mentioned.

Anyway, would like to sync up on what you think about these issues and
whether it's worthwhile to package the changes and submit a patch.

Thanks,

Roman Sulzhyk 


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com