[C++-sig] New Major-Release Boost.Python Development

[Hans Meine]

Am 26.08.2011 um 20:25 schrieb Jim Bosch:
> - … 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.

Correct, great!

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

Probably makes sense, in particular the STL part is an often (understandibly) 
expected feature.

> - Allow Boost.Python wrapped classes to inherit from Python classes.

Yes yes yes!  (list/dict inheritence in particular is /so/ useful.)

> - Some limited degree of priority-based overload matching.  Not sure how 
best to approach this one yet, though.

A related goal (also template-related) is better support for error messages in 
the face of overloaded functions.  In our VIGRA library [1], we have a lot of 
overloaded functions performing image analysis tasks on NumPy arrays.  
Currently, we face the following problems:

- The automatically generated signatures in the docstrings are hard to read.  
Don’t know if there is a better way of presenting signatures of heavily 
templated code (improvements from the error messages of modern compilers or 
STLfilt come to my mind), or if there should simply be a hook for custom 
postprocessing.  (Maybe just __doc__ being writeable from Python?)

- The same goes for error messages when calling with the wrong arguments.

- Furthermore, we have custom converters that check certain properties of the 
passed arrays, e.g. dimensionality, memory layout, or dtype.  With 
overloading, all variants are tried in turn, but there’s no good way to 
"collect" error messages, and tell the user why no registered overload would 
match.  (The C++ signatures don’t necessarily give the user enough 
information.)

My feeling is that all this is strongly related to the features you already 
have in mind, but hopefully my notes help in steering this into an even 
better, more general direction.

Oh, and there’s another missing feature:

- Better support for introspection, e.g. by the ’inspect’ module or 
documentation tools.

Looking forward to a "more accessible" BPL,
  Hans^

[1] http://hci.iwr.uni-heidelberg.de/vigra/doc/vigranumpy/index.html