[C++-sig] [Boost.Python v3] Features and Scope

[Dave Abrahams]

on Fri Aug 26 2011, Jim Bosch <talljimbo-AT-gmail.com> wrote:

> On 08/26/2011 01:09 PM, Dave Abrahams wrote:
>>
>> Well, speaking for myself, mostly time.  I'd be inclined to do a rewrite
>> along the lines of the langbinding ideas if I had time.
>>
>
> I had only been vaguely aware of langbinding until I followed up on
> your last email.  It's a very nice separation, though after bad
> experiences using SWIG I am a little wary about trying to build a
> one-size-fits-all front-end for different languages.
>
> It seems like a reasonable way to proceed would be to try to convert
> Boost.Python to the langbinding interface, but not be obsessive about
> avoiding Python-specific hacks in the frontend right now.  

Absolutely perfect; that's what I was thinking.

> Once we're more feature-complete in Python, we can worry about finding
> language-agnostic ways to do things that weren't anticipated in the
> original langbinding design.
>
>> Another thing I think should be examined and refreshed is the
>> documentation style.
>
> Agreed.  And I wouldn't just limit it to the official documentation;
> there are a lot of little tidbits of useful but often very old
> Boost.Python knowledge scattered around the internet (often on
> Python-affiliated sites or wikis).  It'd be nice to unify a lot of
> that, or at least update the obsolete stuff and add links to a more
> complete set of official documentation.

Sure.

>> Good.  Although, if I were you I would also carefully re-examine the
>> core to see if it has the best design.
>
> I wasn't originally planning on doing a full re-evaluation, but after
> looking over the langbinding proposal and hearing some of the other
> ideas, I think that will probably be necessary.

Happy to discuss with you anywhere you get stuck.  By the way, there's
actually a bunch of langbinding code checked into the SVN repo
somewhere.  Ah, here:
http://svn.boost.org/svn/boost/sandbox/langbinding/


>> on Thu Aug 25 2011, Ralf Grosse-Kunstleve<rwgrosse-kunstleve-AT-lbl.gov>  wrote:
>> <snip>
>>> Troy and Ravi have done a significant amount of work.
>>
>> Yes, and hopefully integrating that could be part of any next steps.
>>
>>> I hope they will comment for themselves.
>
> I was under the impression their work had already been integrated into
> Boost.Python v2.  Is there a large repository of additional
> Boost.Python work elsewhere that I should be aware of?

It's my impression that the integration was stalled due to Ralf's
concerns about object code size.  But I could be wrong.

>> Interesting idea.  How does sharing types across multiple modules work
>> in that scenario?
>
> Hmm.  I'm guessing the global type registry would still be the
> default, and per-module registries would override these when
> available?  It sounds like Stefan has a clear use case in mind, and
> I'd be curious to know what it is.

Me too.

>> on Fri Aug 26 2011, Jim Bosch<talljimbo-AT-gmail.com>  wrote:
>>
>>> On 08/26/2011 04:17 AM, Neal Becker wrote:
>>>> What sort of improvements did you have in mind?
>>>
>>> My list includes:
>>>
>>> - Propagating constness to Python (essentially already done as an
>>> extension, but it could have a much nicer interface if I could mess
>>> with class_ itself).
>>
>> Oooh, now that one is tricky.  I'd like to see the design you have in
>> mind.  Python doesn't have constness; it has immutability, which is
>> subtly different.
>
> Essentially, C++ objects returned as const references, pointers, or
> smart pointers get converted into a Python proxy object with methods
> that forward to the real wrapped object, but only if those methods are
> marked as const.  The proxy objects have rvalue converters but no
> lvalue converters.  

I like it!

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com