1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
|
.. -*- mode: rst -*-
====================================
Boost.Python_ TODO list |(logo)|__
====================================
.. |(logo)| image:: ../../boost.png
:alt: Boost
:class: boost-logo
__ ../../index.htm
.. _`Boost.Python`: index.html
: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)
.. contents:: Outline
.. _`LICENSE_1_0.txt`: ../../LICENSE_1_0.txt
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
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
callback classes, solve some "dangling reference" problems, and
optimize the calling of non-overridden virtual functions.
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
--------------------------
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
--------------------------------
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
already in Luabind_.
.. _Luabind: http://luabind.sf.net
Type Converters
===============
Lvalue conversions from non-const ``PyTypeObject*``\ s
------------------------------------------------------
http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1662717
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`__.
__ 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
---------------------
http://aspn.activestate.com/ASPN/Mail/Message/1411366
``void*`` conversions
---------------------
Pointers to *cv* ``void`` should be able to be passed and
returned as opaque values.
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
---------------------
Review and possibly incorporate changes from `Lijun Qin`_ at
http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1771145
.. _`Lijun Qin`: mailto:qinlj-at-solidshare.com
Ownership Metadata
------------------
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.
Documentation
=============
Builtin Converters
------------------
Builtin correspondences between builtiin Python types and C++
types need to be documented
Internals
---------
The structure of the framework needs to get documented; `Brett
Calcott`_ has promised to turn `this document`__ into something fit
for users
__ doc/internals.html
.. _`Brett Calcott`: mailto:brett.calcott-at-paradise.net.nz
Large Scale
===========
Full Threading Support
----------------------
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.
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
------------------------------
http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1673338
NumArray Support Enhancements
-----------------------------
Consider integrating the enhancements described in
http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1757092
``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
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.
.. _`Dirk Gerrits`: mailto:dirk-at-gerrits.homeip.net
|
