Boost.Python TODO list 
-
-| copyright: | Copyright David Abrahams 2003. Use, modification, and + |
|---|---|
| Copyright: | +Copyright David Abrahams 2003. Use, modification, and distribution are subject to the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at -http://www.boost.org/LICENSE_1_0.txt) | -
- Class Support
- Base Class for Virtual Function Callback Wrappers @@ -39,39 +40,40 @@ distribution are subject to the Boost Software License, Version
- Type Converters
-
-
- Lvalue conversions from non-const PyTypeObject*s +
- Lvalue conversions from non-const PyTypeObject*s
- Converter Scoping -
- FILE* conversions -
- void* conversions -
- Post-Call Actions -
- PyUnicode Support -
- Ownership Metadata +
- boost::tuple +
- FILE* conversions +
- void* conversions +
- Post-Call Actions +
- PyUnicode Support +
- Ownership Metadata
- - Documentation
Class Support
-Base Class for Virtual Function Callback Wrappers
+Class Support
+Base Class for Virtual Function Callback Wrappers
- http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1456023 (bottom of message)
- http://mail.python.org/pipermail/c++-sig/2003-August/005297.html -(search for VirtualDispatcher) describes how callback classes +(search for VirtualDispatcher) describes how callback classes can swap ownership relationship with their Python wrappers.
- http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1860301 describes how this can also be used to considerably simplify @@ -80,30 +82,30 @@ optimize the calling of non-overridden virtual functions.
Miscellaneous
-Support for Enums with Duplicate Values
+Miscellaneous
+Support for Enums with Duplicate Values
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.
Functions
-Wrapping Function Objects
+Functions
+Wrapping Function Objects
-It should be possible to wrap classes which support operator() +
It should be possible to wrap classes which support operator() as Python methods.
http://mail.python.org/pipermail/c++-sig/2003-August/005184.html
"Best Match" Overload Resolution
+"Best Match" Overload Resolution
-Overload resolution currently depends on the order in which def +
Overload resolution currently depends on the order in which def calls are made (preferring later overloads). This should be changed so that the best-matching overload is always selected. This may await Langbinding integration, since the technology is @@ -111,49 +113,55 @@ already in Luabind.
Type Converters
-Lvalue conversions from non-const PyTypeObject*s
+Type Converters
+Lvalue conversions from non-const PyTypeObject*s
http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1662717
Converter Scoping
+Converter Scoping
http://article.gmane.org/gmane.comp.python.c++/2044
If this gets done at all, it is going to happen in conjunction with Luabind integration.
FILE* conversions
+boost::tuple
++Conversions to and from Python would be nice. See +http://news.gmane.org/find-root.php?message_id=%3cuvewak97m.fsf%40boost%2dconsulting.com%3e+
void* conversions
+void* conversions
-Pointers to cv void should be able to be passed and +Pointers to cv void should be able to be passed and returned as opaque values.
Post-Call Actions
+Post-Call Actions
From-Python converters should be passed an extra reference to a chain of post-call actions in the Policies object, where they can register an additional action. See the end of http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1755435
PyUnicode Support
+PyUnicode Support
Review and possibly incorporate changes from Lijun Qin at http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1771145
Ownership Metadata
+Ownership Metadata
In the thread at http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1860301, @@ -164,16 +172,16 @@ count on an object doesn't tell us anything about the lifetime of its data.
Documentation
-Builtin Converters
+Documentation
+Builtin Converters
Builtin correspondences between builtiin Python types and C++ types need to be documented
Internals
+Internals
The structure of the framework needs to get documented; Brett Calcott has promised to turn this document into something fit @@ -181,10 +189,10 @@ for users
Large Scale
-Full Threading Support
+Large Scale
+Full Threading Support
Various people have proposed patches to improve threading support in Boost.Python: see the thread at @@ -194,33 +202,33 @@ 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.
Langbinding
+Langbinding
This project to generalizes Boost.Python to work for other languages, initially Lua. See discussions at http://lists.sourceforge.net/lists/listinfo/boost-langbinding
Refactoring and Reorganization
+ -NumArray Support Enhancements
+NumArray Support Enhancements
Consider integrating the enhancements described in http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1757092
PyFinalize Safety
+PyFinalize Safety
Currently Boost.Python has several global (or function-static) objects whose existence keeps reference counts from dropping to zero until the Boost.Python shared object is unloaded. This can cause a crash because when the reference counts do go to zero, there's no interpreter. In order to make it safe to call -PyFinalize() we must register an atexit routine which +PyFinalize() we must register an atexit routine which destroys these objects and releases all Python reference counts so that Python can clean them up while there's still an interpreter. Dirk Gerrits has promised to do this job.
@@ -228,11 +236,5 @@ interpreter. Dirk
- diff --git a/todo.txt b/todo.txt index c8a9be98..fb4f1c3c 100644 --- a/todo.txt +++ b/todo.txt @@ -91,6 +91,13 @@ Converter Scoping __ Langbinding_ + +``boost::tuple`` +---------------- + + Conversions to and from Python would be nice. See + http://news.gmane.org/find-root.php?message_id=%3cuvewak97m.fsf%40boost%2dconsulting.com%3e + ``FILE*`` conversions ---------------------