1.. -*- mode: rst -*- 2 3==================================== 4 Boost.Python_ TODO list |(logo)|__ 5==================================== 6 7.. |(logo)| image:: ../../boost.png 8 :alt: Boost 9 :class: boost-logo 10 11__ ../../index.htm 12 13.. _`Boost.Python`: index.html 14 15:copyright: Copyright David Abrahams 2003. Use, modification, and 16 distribution are subject to the Boost Software License, Version 17 1.0. (See accompanying file `LICENSE_1_0.txt`_ or copy at 18 http://www.boost.org/LICENSE_1_0.txt) 19 20.. contents:: Outline 21 22.. _`LICENSE_1_0.txt`: ../../LICENSE_1_0.txt 23 24Class Support 25============= 26 27Base Class for Virtual Function Callback Wrappers 28------------------------------------------------- 29 30* http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1456023 31 (bottom of message) 32 33* http://mail.python.org/pipermail/c++-sig/2003-August/005297.html 34 (search for ``VirtualDispatcher``) describes how callback classes 35 can swap ownership relationship with their Python wrappers. 36 37* http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1860301 38 describes how this can also be used to considerably simplify 39 callback classes, solve some "dangling reference" problems, and 40 optimize the calling of non-overridden virtual functions. 41 42Miscellaneous 43============= 44 45Support for Enums with Duplicate Values 46--------------------------------------- 47 48 Scott Snyder provided a patch; Dave was dissatisfied for some 49 reason, but maybe it should just be applied if no further action 50 occurs http://aspn.activestate.com/ASPN/Mail/Message/1824616. 51 52 53Functions 54========= 55 56Wrapping Function Objects 57-------------------------- 58 59 It should be possible to wrap classes which support ``operator()`` 60 as Python methods. 61 62 http://mail.python.org/pipermail/c++-sig/2003-August/005184.html 63 64 65"Best Match" Overload Resolution 66-------------------------------- 67 68 Overload resolution currently depends on the order in which ``def`` 69 calls are made (preferring later overloads). This should be 70 changed so that the best-matching overload is always selected. 71 This may await Langbinding_ integration, since the technology is 72 already in Luabind_. 73 74 .. _Luabind: http://luabind.sf.net 75 76Type Converters 77=============== 78 79Lvalue conversions from non-const ``PyTypeObject*``\ s 80------------------------------------------------------ 81 82 http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1662717 83 84Converter Scoping 85----------------- 86 87 http://article.gmane.org/gmane.comp.python.c++/2044 88 89 If this gets done at all, it is going to happen in conjunction 90 with `Luabind integration`__. 91 92 __ Langbinding_ 93 94 95``boost::tuple`` 96---------------- 97 98 Conversions to and from Python would be nice. See 99 http://news.gmane.org/find-root.php?message_id=%3cuvewak97m.fsf%40boost%2dconsulting.com%3e 100 101``FILE*`` conversions 102--------------------- 103 104 http://aspn.activestate.com/ASPN/Mail/Message/1411366 105 106``void*`` conversions 107--------------------- 108 109 Pointers to *cv* ``void`` should be able to be passed and 110 returned as opaque values. 111 112Post-Call Actions 113----------------- 114 115 From-Python converters should be passed an extra reference to a 116 chain of post-call actions in the Policies object, where they can 117 register an additional action. See the end of 118 http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1755435 119 120``PyUnicode`` Support 121--------------------- 122 123 Review and possibly incorporate changes from `Lijun Qin`_ at 124 http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1771145 125 126 .. _`Lijun Qin`: mailto:qinlj-at-solidshare.com 127 128Ownership Metadata 129------------------ 130 131 In the thread at 132 http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1860301, 133 Niall Douglas describes an idea for solving some "false" 134 dangling pointer/reference return errors by attaching data about 135 objects which lets the framework determine that the reference 136 count on an object doesn't tell us anything about the lifetime 137 of its data. 138 139Documentation 140============= 141 142Builtin Converters 143------------------ 144 145 Builtin correspondences between builtiin Python types and C++ 146 types need to be documented 147 148Internals 149--------- 150 151 The structure of the framework needs to get documented; `Brett 152 Calcott`_ has promised to turn `this document`__ into something fit 153 for users 154 155 __ doc/internals.html 156 157 .. _`Brett Calcott`: mailto:brett.calcott-at-paradise.net.nz 158 159 160Large Scale 161=========== 162 163Full Threading Support 164---------------------- 165 166 Various people have proposed patches to improve threading support 167 in Boost.Python: see the thread at 168 http://aspn.activestate.com/ASPN/Mail/Message/1826544 and 169 http://aspn.activestate.com/ASPN/Mail/Message/1865842 for some 170 examples. The only problem is that these are incomplete 171 solutions and verifying that we *do* have a complete solution is 172 going to take some time and attention. 173 174Langbinding 175----------- 176 177 This project to generalizes Boost.Python to work for other 178 languages, initially Lua. See discussions at 179 http://lists.sourceforge.net/lists/listinfo/boost-langbinding 180 181Refactoring and Reorganization 182------------------------------ 183 184 http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1673338 185 186NumArray Support Enhancements 187----------------------------- 188 189 Consider integrating the enhancements described in 190 http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1757092 191 192``PyFinalize`` Safety 193--------------------- 194 195 Currently Boost.Python has several global (or function-static) 196 objects whose existence keeps reference counts from dropping to 197 zero until the Boost.Python shared object is unloaded. This can 198 cause a crash because when the reference counts *do* go to zero, 199 there's no interpreter. In order to make it safe to call 200 ``PyFinalize()`` we must register an ``atexit`` routine which 201 destroys these objects and releases all Python reference counts 202 so that Python can clean them up while there's still an 203 interpreter. `Dirk Gerrits`_ has promised to do this job. 204 205 .. _`Dirk Gerrits`: mailto:dirk-at-gerrits.homeip.net 206 207
