+Scott Snyder provided a patch; Dave was dissatisfied for some +reason, but maybe it should just be applied if no further action +occurs http://aspn.activestate.com/ASPN/Mail/Message/1824616.+
It should be possible to wrap classes which support operator() as Python methods.
@@ -79,7 +101,7 @@ as Python methods.
Overload resolution currently depends on the order in which def calls are made (preferring later overloads). This should be @@ -88,29 +110,16 @@ This may await Langbinding integrat already in Luabind.
--Enabling the addition of new constructor functors or factory -constructors which aren't in the underlying C++ interface. -Interface still to be decided. Here is a discussion of it:
--http://aspn.activestate.com/ASPN/Mail/Message/1744280-However, I'm pretty sure we can't use the init<>(f) interface here -because it will have to instantiate the code for the wrapped -class' default constructor, which may not exist.
-
http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1662717
http://article.gmane.org/gmane.comp.python.c++/2044
If this gets done at all, it is going to happen in conjunction @@ -118,12 +127,18 @@ with Luabind integration.
+Pointers to cv void should be able to be passed and +returned as opaque values.+
From-Python converters should be passed an extra reference to a chain of post-call actions in the Policies object, where they can @@ -131,23 +146,34 @@ register an additional action. See the end of http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1755435
Review and possibly incorporate changes from Lijun Qin at http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1771145
+In the thread at +http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1860301, +Niall Douglas describes an idea for solving some "false" +dangling pointer/reference return errors by attaching data about +objects which lets the framework determine that the reference +count on an object doesn't tell us anything about the lifetime +of its data.+
Builtin correspondences between builtiin Python types and C++ types need to be documented
The structure of the framework needs to get documented; Brett Calcott has promised to turn this document into something fit @@ -156,27 +182,38 @@ for users
+Various people have proposed patches to improve threading support +in Boost.Python: see the thread at +http://aspn.activestate.com/ASPN/Mail/Message/1826544 and +http://aspn.activestate.com/ASPN/Mail/Message/1865842 for some +examples. The only problem is that these are incomplete +solutions and verifying that we do have a complete solution is +going to take some time and attention.+
This project to generalizes Boost.Python to work for other languages, initially Lua. See discussions at http://lists.sourceforge.net/lists/listinfo/boost-langbinding
http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1673338
Consider integrating the enhancements described in http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1757092
Currently Boost.Python has several global (or function-static) objects whose existence keeps reference counts from dropping to @@ -191,10 +228,10 @@ interpreter. Dirk