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:
<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?
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
himself).
* Support for subclassing boost.python's own metaclass.
Cool.
* 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:
const_aware(class_<T>("class_name"))
.def(...)
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
python_extensions package.
- Make custom registry and template-based conversions more
accessible.
+1
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.
+1
- An actual "boost.python" Python module to make exceptions and other
types used in wrappers easily accessible from Python.
Nice.
- Some limited degree of priority-based overload matching. Not sure
how best to approach this one yet, though.
+1
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.
Thanks!
Jim
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
