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 _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
