Re: [boost] Re: python wrapping question - non standard constructor/destructor

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-10-27 16:49:03

----- Original Message -----
From: "Ullrich Koethe" <u.koethe_at_[hidden]>

> David Abrahams wrote:
> >
> > Ulli,
> >
> > I'm glad to hear you're making progress on Boost.Python. I'll be
starting a
> > short support contract for Boost Python at the end of the week, so
there's a
> > good chance of more progress in the near future. Do you have other
> > outstanding changes which you think I should integrate?

Hi Ulli,

Sorry it's taken so long... by the time this email is sent, I'll be in
Berkeley, ready to start working with Ralf.

> Well, there is a small bug in the overload resolution code for
> operators. Suppose we have two classes A and B, and want to export all
> possible combinations of '*'
>
> def()'ed in A:
>     A * A
>     A * B
>
> def()'ed in B:
>     B * B
>     B * A
>
> Then, B * A is never found during lookup. I have a simple fix for this.

That's curious. Please send the fix along!

> > > PS: So far, I'm very pleased with Boost.Python. I have begun exporting
> > > my VIGRA library, and I haven't had any major problems.

Oh, and I'd like to encourage you to submit VIGRA to boost!

> > > One weak point,
> > > however, is the implementation of customized
'to_python()/from_python()'
> > > functions. For eample, I want to arrange for a float sequence of
length
> > > 3 to be silently accpeted wherever an RGBValue object is expected.
Have
> > > you any ideas here?
> >
> > Why not just add an overload which takes a python::ref, and handle the
> > type/concept checking yourself within the overload?
> >
>
> Perhaps you are right. But it seems to me that from_python() would be
> the right place for this to avoid redundancy.
>
> I've actually implemented a partial solution: I've refactored a new base
> class 'python_extension_class_converters_base' (which contains function
> implementations) out of 'python_extension_class_converters', and the
> latter only defines the friend functions by trivially forwarding the
> work to the base class' members. This makes it relatively easy to
> explicitly instantiate 'python_extension_class_converters' for a
> particular class.

Sorry, I don't understand. Isn't that already easy?

> However, if I don't want to define all converter
> variants, this is quite inconvenient because corresponding changes have
> to be made for cross_module support.

Yep. But I'm afraid I still can't envision what this buys you.

> A principled solution would be to allow for switching on and off the
> instantiation of converter functions. This might be possible by means of
> a template technique similar to the one used for operators. Something
> like
>
>  template <..., int ConverterFlags = all_converters>
>  class python_extension_class_converters
>  : python_define_converter_value<..., ConverterFlags & converter_value>,
>    python_define_converter_ptr<..., ConverterFlags & converter_ptr>,
>    ...
>
> where python_define_converter_...<..., 0>  would do nothing. If a
> non-default converter is needed, the default is left out in the flag,
> and the replacement explicitly defined. But I'm afraid this technique
> will lead to even more code bloat and longer compile times (apart from
> not working directly on MSVC). There must be a simpler way!

I think I see what you're trying to do now. Why don't we provide a
conversion hook that deals with failures in the default conversions? The
basic idea is to try the default conversion first, then consult the hook (if
any) to try other conversions. The mechanism could be as simple as a traits
class which is specialized to override behaviors.

> Another unsolved problem seems to be the base class conversion for smart
> pointers. Or am I missing something here (or made a stupid mistake)?

No, I think you're probably right. We'll get to that eventually, I'm sure.

BTW, I don't suppose your group is interested in hiring me to support
Boost.Python for a while?

===================================================
  David Abrahams, C++ library designer for hire
 resume: http://users.rcn.com/abrahams/resume.html

        C++ Booster (http://www.boost.org)
          email: david.abrahams_at_[hidden]
===================================================