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

[David Abrahams]

Roman Sulzhyk <roman_sulzhyk at yahoo.com> writes:

> 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 

Thanks!

> and especially pyste. 

Thanks to Nicodemus and his willingness to keep an open mind!

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

I think you're confusing overloading and overriding.  It sounds like
you don't plan to override these virtual functions, and you'd like
Pyste not to generate the dispatching code and perhaps not generate
the derived wrapper class when there's no dispatching code at all.  Do
you also want Pyste to *not* wrap some some specific function
overloads?

> 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
             ^^^^^^^^^^
"Overridden" again?

And why only virtual functions?  I'd be really surprised if Pyste
failed to expose *all* of the functions publicly inherited from base
classes but if that's the case, it should probably be fixed.

BTW, "methods" is a Python term; the C++ term is "function" or "member
function".  When discussing two languages at once it gets really
confusing if you're not very careful with terminology.

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

That's called an "exception specification", not an "exception
declaration".  Pyste couldn't handle it due to a missing feature in
GCC_XML, which has just been added today.  I think this will probably
be handled very soon.

> 3. Specifying the set_policy() for virtual functions
>
> It appears that the policy setting is ignored for virtual function
> declarations.

What makes you think so?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com