[C++-sig] [Boost.Python v3] Features and Scope
talljimbo at gmail.com
Sat Aug 27 01:39:11 CEST 2011
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. 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.
> 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.
> on Thu Aug 25 2011, Ralf Grosse-Kunstleve<rwgrosse-kunstleve-AT-lbl.gov> wrote:
>> 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?
I am aware of Py++ and the extensions associated with it, and some of
that could definitely go into Boost.Python proper (and I think I've
heard Roman state that he wouldn't have a problem with someone else
doing the work to make it so, and he just didn't have time to do it
>> * Support for subclassing boost.python's own metaclass.
>> * A per-module type registry, to avoid conflicting converters in
>> multi-module projects.
> 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.
> on Fri Aug 26 2011, "Niall Douglas"<s_sourceforge-AT-nedprod.com> wrote:
>> About a year ago I promised someone in here I'd refactor the BPL
>> interface to native code to support calling a list of functors every
>> time BPL goes in or out of native code. This would allow the Python
>> GIL to be released or reacquired, or indeed many other useful things
>> e.g. benchmarking.
> Sounds useful.
This is one of the areas - GIL, threading, etc. - where I'm less
knowledgeable, especially when multiple platforms are involved. It
sounds like a very useful feature for a lot of people, but I have to
admit I probably wouldn't dive into this without a lot of backup.
> 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 essentially wrote a wrapper around class_ to check for
constness of member functions and make the proxy class. When you use
class_ directly, there's no const-correctness, but you can do:
etc., to get const-correct wrappers. It doesn't work at all well with
visitors, though, and I think I could find a better syntax with the
ability to mess with class_ itself.
Most of the current design can be found in the boost sandbox, in the
>> - Make custom registry and template-based conversions more
>> The former may just need more documentation, but the rvalue converters
>> in particular don't seem to have been intended as part of the public
>> API originally, and I think they're an important part of the
>> library. Template-based conversions are even more buried in the
>> details - you have to specialize five or six classes to get it
>> working. I'd like to make it possible to create a template-based
>> conversion by (partial) specializing just one traits class.
> Hmm, well, IIRC anything you do by pure partial specialization does not
> go in the registry and can't participate in cross-module communication,
> as it's entirely static. I guess we need a more formal separation of the
> two basic techniques for conversion, not to mention documentation, so
> people know to what they're opting in.
Yeah, that's exactly right. To get it to work cross-module you have to
include a header with the specializations in all modules (and worse, in
all wrapper source files in those modules). It makes things a little
too magical for my taste, but I don't see a way around that, and
template-based converters are really helpful in wrapping array-heavy
numerical code. Documentation is indeed a big part of this.
>> - Automatic conversions for newer boost libraries (Fusion, Pointer
>> Container, and Filesystem are at the top of my list), and more for the
>> STL and iostreams standard libraries. I'd like to integrate the
>> indexing suite (v2) into Boost.Python proper.
> Interesting and useful improvements.
>> - Allow Boost.Python wrapped classes to inherit from Python classes.
>> - An actual "boost.python" Python module to make exceptions and other
>> types used in wrappers easily accessible from Python.
>> - Some limited degree of priority-based overload matching. Not sure
>> how best to approach this one yet, though.
> This is a solved problem... just not in Boost.Python. Daniel Wallin
> worked it out for luabind and we were going to incorporate it into
> langbinding. Happy to discuss it further.
That's great to hear. I'll have to spend some time looking at luabind.
I'm sure I'll have more questions later.
More information about the Cplusplus-sig