Boost.Python TODO list Boost

copyright:Copyright David Abrahams 2003. See accompanying license for terms of use.

Outline

  • Class Support
    • Base Class for Virtual Function Callback Wrappers
  • Functions
    • Wrapping Function Objects
    • "Best Match" Overload Resolution
    • Injected Constructors
  • Type Converters
    • Lvalue conversions from non-const PyTypeObject*s
    • Converter Scoping
    • FILE* conversions
    • Post-Call Actions
    • PyUnicode Support
  • Documentation
    • Builtin Converters
    • Internals
  • Large Scale
    • Langbinding
    • Refactoring and Reorganization
    • NumArray Support Enhancements
    • PyFinalize Safety

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.

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.

Injected Constructors

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.

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.

FILE* conversions

http://aspn.activestate.com/ASPN/Mail/Message/1411366

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

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

Large Scale

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.


View document source. Generated on: 2003-09-11 11:04 UTC. Generated by Docutils from reStructuredText source.