[C++-sig] make_constructor and extending from python

[Jim Bosch]

On 02/03/2012 03:13 PM, Holger Brandsmeier wrote:
> Dear list,
>
> how can I have a static member function that acts like a constructor
> in a Wrapper, i.e. I have a class that I want to extend from python?
>
> I have a wrapper class around a class (PfemSpace) that has this static
> member functions:
>
>    static RCP<PfemSpaceWrapperT>  create( ... )
>    {
>      RCP<PfemSpaceWrapperT>  ret(new PfemSpaceWrapperT( ... ));
>
>      ret->setThisRCP(ret);
>      return ret;
>    }
>
> This method is exported via
>    .def("__init__", make_constructor(&ClassWrapperT::create ) )
>
> This works without errors, but when I use this from python via
>
> class PfemSpaceStaticCond(PfemSpace):
>    def __init__(self, ...):
>      super(PfemSpaceStaticCond, self).__init__(...)
>
>    def visit_createFemData(self):
>      print '## [PfemSpaceStaticCond_init] visit_createFemData'
>
> Here I call the constructor that I exported via make_constructor in
> __init__(). Unfortunately the member function visit_createFemData that
> I override in python never gets called. When I use a "real"
> constructor instead of the one exported via make_constructor() then
> the function visit_createFemData gets called.
>
> I assume the error is somewhere that with a real constructor
> boost::python can call an inplace constructor, while with my
> make_constructor it can't. Is there some way to have the needed
> functionality with make_constructor?
>
> Note: today I came to the conclusion that I a read constructor instead
> of a static member function is not an option for me due to the issues
> I wrote in my previous mail "storing weak_ptr to this in classes
> extended from python". That previous mail is actually from yesterday,
> but it originally got rejected because I send it from a wrong email
> address, so I'm sorry that you are receiving two mails from me today.
> For a moment I was very happy that this "static constructor-like
> function in the Wrapper class" would solve all my problems, but I am
> still missing something.
>

I'm hoping my reply to your other email may give you a way forward, 
because I think there's a possibility that you've run into a real 
limitation of Boost.Python here.

The only thing I can think of is to override __new__, and not override 
__init__; that might get the make_constructor version called.

But I'm just guessing.  make_constructor, useful as it is, just doesn't 
seem to really have the polish the rest of Boost.Python has, and I 
wouldn't be surprised if it just doesn't work here.  After all, if 
you're wrapping a function that returns a smart pointer, there's no 
guarantee that contains an instance of the wrapper class needed to 
support Python-side polymorphism rather than just an instance of the C++ 
base class.

Jim