目录

• 摘要
• 简介
• Boost.Python 设计目标
• Hello Boost.Python World
• 库概览
  • 暴露类(Exposing Classes)
    • 构造器(Constructors)
    • 数据成员和属性(Properties)
    • 操作符重载
    • 继承
    • 虚函数
    • 更深层次的反射即将出现(Deeper Reflection on the Horizon)?
  • 序列化(Serialization)
  • 对象接口(Object interface)
• 从混合的思路思考(Thinking hybrid)
• 开发历史
• 结论
• 引用
• 脚注

摘要

Boost．Python是一个开源的C++程序库，提供类似IDL的接口来把C++类和函数绑定到Python。借助于C++强大的编译时内省(introspection)能力和最新的元编程(metaprogramming)技术，它完全用C++来实现，而不用引入新的语法。Boost.Python丰富的特性和高级接口使从底层起按混合系统的方式设计组件成为可能，从而使程序员可以轻松和连贯的同时使用C++高效的编译时多态和Python极其方便的运行时多态。

简介

作为两门语言，python和C++在很多方面不一样。C++被编译为机器码，python被解释(interpreted)执行。Python的动态类型(type)系统经常被认为是灵活性的基础，C++的静态类型是效率的基石。C++有复杂艰深的编译时元语言(meta-language)，而在python里，实际上一切都在运行时发生。然而对很多程序员来说，这些不同恰好意味着Python和C++是彼此的完美补足。Python 程序里的性能瓶颈部分可以用C++来重写，从而最大化速度。强大的C++程序库的作者选择Python作为中间件(middleware)语言，从而获得灵活的系统集成能力。此外，表面的不同掩盖了二者非常类似的一些地方：

• ‘C’-家族的控制结构 (if，while，for…)
• 支持面向对象(object-orientation)，函数式编程(functional programming)，泛型编程(generic programming)(它们都是多范 式语言(multi-paradigm languages))
• 认同语法可变性(syntactic variability)在提高代码的可读性和表达力上的重要作用，提供了对操作符重载的广泛支持
• 高级概念，如集合(collections)，迭代器(iterators)等
• 高级封装机制(C++: namespaces，Python: modules)支持可重用程序库的设计
• 异常处理机制提供了有效的错误管理
• 被普遍使用的C++习惯用语，如handle/body classes和引用被计数的智能指针(reference-counted smart pointers)对应Python 的引用语义(reference semantics)

考虑到Python丰富的’C'协作API，原则上把C++的类型和函数以类似于暴露给C++的接口暴露给Python是可能的。然而，单是Python提供的这种设施对集成C++的支持比较弱。和C++，Python相比，’C'的抽象机制非常初级，而且完全不支持异常处理。’C'扩展模块的作者必须手动管理引用计数，这不但让人恼火的麻烦和单调，还极度容易出错。传统的扩展模块容易产生重复的样板代码(boilerplate code)，从而难于维护，尤其是要包装的API很复杂时。

上述限制导致了一些包装系统的开发。SWIG_ 可能是集成C/C++和Python的包装系统中最流行的。一个更近的例子是 SIP ，它专门设计来提供 Qt 图形用户界面库的Python接口。SWIG和SIP都引入了它们专有的语言来实现语言间绑定。这当然有它的好处，但不得不应付三种不同的语言(Python，C/C++和接口语言)也带来了实际的和心理上的困难。 CXX 软件包展示出它是一个有趣的包装系统。它说明了至少一部份Python ‘C’ API可以通过用户友好得多的C++接口来包装和表现。然而，和SWIG和SIP不一样，CXX不支持把C++类包装成新的Python类型。

Boost.Python 的特性和目标和很多这样的系统有相当程度的重叠。就是说，Boost.Python试图最大化便利性和灵活性，而不引入单独的包装语言。相反，它在幕后用静态元编程技术管理很多复杂问题，赋予了用户通过高级C++接口来包装C++类和函数的能力，Boost.Python也在如下领域超越了早期的系统：

• C++虚函数支持，虚函数可以用Python来覆盖(override)
• 在整个生命周期内对低级指针和引用进行全面管理的设施
• 对把扩展(extensions)组织成Python packages的支持，通过中心注册表(central registry)来进行语言间类型转换
• 安全而便利的连接强大的Python序列化引擎(pickle)的机制
• C++的lvalue和rvalue的一致的处理规则，这只能来自对Python和C++两者的类型系统的深入理解。

鼓舞Boost.Python开发的关键发现是，传统扩展开发中的大量样板代码都可以通过C++编译时内省来消除。被包装的C++函数的每个参数都必须根据参数类型从Python对象里取出来。类似地，函数返回值的类型决定了返回值如何从C++转换成Python。参数类型和返回值类型当然都是每个函数的类型的一部分，正是从这里，Boost.Python推导出了大部分需要的信息。

这种方法导向了 用户引导的包装 ：尽可能的用纯C++的框架直接从要包装的代码里取得信息，这以外的信息由用户显式提供。大多数引导是自动的，很少需要真正的干涉。因为写接口规范和写被暴露的代码的是同一门全功能语言，当需要取得控制时用户有了空前强大的能力。

Boost.Python 设计目标

Boost.Python的首要目标是让用户只用C++编译器就能向Python暴露C++类和函数。大体来讲，允许用户直接从Python操作C++对象。

然而，有一点很重要，那就是不要 过于 按字面翻译所有接口：必须考虑每种语言的惯用语。例如，虽然C++和Python都有迭代器的概念，表达方式却很不一样。Boost.Python必须能连接这些不同的接口。

必须把Python用户和C++接口的微小误用造成的崩溃隔离。出于同样原因，应该把C++用户和低级Python ‘C’ API隔离，容易出错的C接口，比如手动引用计数管理，原始的(raw)PyObject指针，应该用更加健壮的(more-robust)替代物来取代。

支持基于组件的开发是至关重要的，因此被暴露在一个扩展模块里的C++类型应该能够被传递给被暴露在另一个模块中的函数，而不丢失重要的信息，比如说C++继承关系。

最后，所有的包装必须是 非侵入的(non-intrusive) ，不能修改甚至看不到原始的C++代码。对只能看见它头文件和二进制文件的第三方，现有的C++库必须是可包装的。

Hello Boost.Python World

现在来预览一下Boost.Python，并看看它如何改进Python的原始包装功能。下面是我们想暴露的一个函数:

char const* greet(unsigned x)
{
   static char const* const msgs[] = { "hello"，"Boost.Python"，"world!" };

   if (x > 2)
       throw std::range_error("greet: index out of range");

   return msgs[x];
}

用Python的C API和标准C++来包装这个函数，我们需要像这样:

extern "C" // 所有Python交互都使用C链接和调用习惯
{
    // 处理参数/结果转换和检查的包装层
    PyObject* greet_wrap(PyObject* args，PyObject * keywords)
    {
         int x;
         if (PyArg_ParseTuple(args，"i"，&x))    // 取出/检查参数
         {
             char const* result = greet(x);      // 调用被包装的函数
             return PyString_FromString(result); // 结果转换成Python
         }
         return 0;                               // 发生了错误
    }

    // 待包装函数表，函数用这个模块来暴露
    static PyMethodDef methods[] = {
        { "greet"，greet_wrap，METH_VARARGS，"return one of 3 parts of a greeting" }
        ，{ NULL，NULL，0，NULL } // sentinel
    };

    // 模块初始化函数
    DL_EXPORT init_hello()
    {
        (void) Py_InitModule("hello"，methods); // 添加成员函数(method)到模块
    }
}

现在看看我们使用Boost.Python来暴露它时的包装代码:

#include <boost/python.hpp>
using namespace boost::python;
BOOST_PYTHON_MODULE(hello)
{
    def("greet"，greet，"return one of 3 parts of a greeting");
}

下面是使用它的代码:

>>> import hello

>>> for x in range(3):
...     print hello.greet(x)
...
hello
Boost.Python
world!

C API版本要冗长的多，此外，一些它没有正确处理的地方值得提到：

• 原来的函数接受无符号整数，Python ‘C’ API仅仅提供了提取有符号整数的方式。如果我们试图向hello.greet传递负数Boost.Pyt hon版将抛出Python异常，而Python ‘C’ API版则会继续像在C++实现中那样转换负数到无符号数(通常包装成某种很大的数)，然后 把不正确的转换结果传给被包装函数。
• 这引起了第二个问题：如果函数的参数大于2，C++ greet()被调用时会抛出异常。典型的，如果C++异常跨越C编译器生成的代码的 边界传递，会导致崩溃。正如你在第一个版本中看到的，那儿没有C++脚手架(scaffolding)来防止崩溃发生。被Boost.Python包装 过的函数自动包含了异常处理层，它把未处理的C++异常翻译成相应的Python异常，从而保护了Python用户。
• 一个更微妙的限制是，Python ‘C’ API的参数转换机制只能以一种方式取得整数x。如果一个Python long 对象(任意精度整数) 碰巧可以转换成(fit in)unsigned int而不能转换成signed long，PyArg_ParseTuple不能对其进行转换。同样如果被包装的C++ 类包含用户定义的隐式operator unsigned int()转换，它永远不能处理。Boost.Python的动态类型转换注册表允许用户任意添加 转换方法。

库概览

这部分简要描述了库的主要特性。为了避免混淆，忽略了实现细节。

struct World
{
    void set(std::string msg) { this->msg = msg; }
    std::string greet() { return msg; }
    std::string msg;
};

#include <boost/python.hpp>

BOOST_PYTHON_MODULE(hello)
{
    class_<World>("World")
        .def("greet"，&World::greet)
        .def("set"，&World::set)
    ;
}

class_<World>("World")

class_<World> w("World");

w.def("greet"，&World::greet)

class_<World> w("World");
w.def("greet"，&World::greet);
w.def("set"，&World::set);

>>> import hello
>>> planet = hello.World()
>>> planet.set('howdy')
>>> planet.greet()
'howdy'

>>> planet = hello.World()

struct World
{
    World(std::string msg); // 添加的构造器
    ...

class_<World>("World"，init<std::string>())
    .def(init<double，double>())
    ...

class <World>("World"，init<std::string>())
        .def(init<double，double>())
        ...

class_<World>("World"，init<std::string>())
    .def_readonly("msg"，&World::msg)
    ...

>>> planet = hello.World('howdy')
>>> planet.msg
'howdy'

class_<World>("World"，init<std::string>())
    .add_property("msg"，&World::greet，&World::set)
    ...

>>> class World(object):
...     __init__(self，msg):
...         self.__msg = msg
...     def greet(self):
...         return self.__msg
...     def set(self，msg):
...         self.__msg = msg
...     msg = property(greet，set)

class_<rational<int> >("rational_int")
  .def(init<int，int>()) // constructor，e.g. rational_int(3，4)
  .def("numerator"，&rational<int>::numerator)
  .def("denominator"，&rational<int>::denominator)
  .def(-self)        // __neg__ (unary minus)
  .def(self + self)  // __add__ (homogeneous)
  .def(self * self)  // __mul__
  .def(self + int()) // __add__ (heterogenous)
  .def(int() + self) // __radd__

class_<Derived，bases<Base1，Base2> >("Derived")
     ...

>>> class L(list):
...      def __init__(self):
...          pass
...
>>> L().reverse()
>>>

>>> class D(SomeBoostPythonClass):
...      def __init__(self):
...          pass
...
>>> D().some_boost_python_method()
Traceback (most recent call last):
  File "<stdin>"，line 1，in ?
TypeError: bad argument type for built-in operation

//
// 要包装的接口:
//
class Base
{
 public:
    virtual int f(std::string x) { return 42; }
    virtual ~Base();
};

int calls_f(Base const& b，std::string x) { return b.f(x); }

//
// 包装代码
//

// 分派者类(Dispatcher class)
struct BaseWrap : Base
{
    // 储存指向Python对象的指针
    BaseWrap(PyObject* self_) : self(self_) {}
    PyObject* self;

    // 当f没有被覆盖(override)时的缺省实现
    int f_default(std::string x) { return this->Base::f(x); }
    // 分派实现
    int f(std::string x) { return call_method<int>(self，"f"，x); }
};

...
    def("calls_f"，calls_f);
    class_<Base，BaseWrap>("Base")
        .def("f"，&Base::f，&BaseWrap::f_default)
        ;

>>> class Derived(Base):
...     def f(self，s):
...          return len(s)
...
>>> calls_f(Base()，'foo')
42
>>> calls_f(Derived()，'forty-two')
9

#include <string>

struct World
{
    World(std::string a_msg) : msg(a_msg) {}
    std::string greet() const { return msg; }
    std::string msg;
};

#include <boost/python.hpp>
using namespace boost::python;

struct World_picklers : pickle_suite
{
  static tuple
  getinitargs(World const& w) { return make_tuple(w.greet()); }
};

BOOST_PYTHON_MODULE(hello)
{
    class_<World>("World"，init<std::string>())
        .def("greet"，&World::greet)
        .def_pickle(World_picklers())
    ;
}

>>> import hello
>>> import pickle
>>> a_world = hello.World("howdy")
>>> pickle.dump(a_world，open("my_world"，"w"))

>>> import pickle
>>> resurrected_world = pickle.load(open("my_world"，"r"))
>>> resurrected_world.greet()
'howdy'

object s("hello，world");   // s 管理一个Python字符串

object ten_Os = 10 * s[4]; // -> "oooooooooo"

double x = extract<double>(o);

dict d;
d["some"] = "thing";
d["lucky_number"] = 13;
list l = d.keys();

从混合的思路思考(Thinking hybrid)

因为结合编程语言具有实际的和心理的困难，在进行任何实际开发前决定使用单一的语言是普遍现象。对很多应用来说，性能上的考虑决定了核心算法要用编译语言实现。不幸的是，因为静态类型系统的复杂性，我们为运行时性能要付出开发时间大量增长的代价。经验表明，和开发相应的Python代码比起来，开发可维护的C++代码通常需要更长的时间和艰难得多才能获得的工作经验。即使开发者觉得只用一门编译语言开发挺好，为了用户，他们也经常用某种类型的特别的脚本层来补充系统，哪怕他们永远不会得到同样的好处。

Boost.Python让我们能 think hybrid 。Python可以用来快速搭建新的应用的原型；在开发能工作的系统时，它的易用性和大量的标准库使我们处于领先。需要的话，可以用能工作的代码来找出限制速度的热点(rate-limiting hotspots)。为了最大化性能，这些热点可以用C++来重新实现，然后用Boost.Python绑定来连进已有的高级过程(译注：指Python程序)。

当然，如果一开始就清楚很多算法最后不得不用C++来实现，这种 由顶至下(top-down) 的方法就没那么吸引人了。幸运的是，Boost.Python也允许我们使用 由底至上(bottom-up) 的方法。我们非常成功的把这种方法用在了一个用于科学应用的工具箱软件的开发上。这个工具箱开始主要是一个带Boost.Python绑定的C++类库，接下来有一小段时间增长主要集中在C++部分，随着工具箱变得越来越完整，越来越多新添加的功能可以用Python来实现。

上图是实现新的算法时新添加的C++代码和Python代码的估计比率随时间变化的情况。我们预计这个比率会达到接近70% (Python)。能够主要用Python而不是更困难的静态类型语言来解决新问题，这是我们在Boost.Python上的投入的回报。我们的所有代码都能从Python访问，这使得更广泛的开发者可以用它来快速开发新的应用。

开发历史

Boost.Python的第一版是由Dave Abrahams在Dragon Systems开发的。在那里他非常荣幸的请到Tim Peters作为他的"Python之禅"( "The Zen of Python")导师。Dave的工作之一是开发基于Python的自然语言处理系统。因为最终要被用于嵌入式硬件，系统计算密集的内核总是被假设成要用C++来重写以优化速度和内存需求量(memory footprint) [1] 。这个项目也想用Python测试脚本 [2] 来测试所有的C++代码。当时我们知道的绑定C++和Python的唯一工具是 SWIG ，但那时它处理C++的能力比较弱。要说在那时就对Boost.Python所使用方法的可能优越之处有了什么深刻洞见，那是骗人的。Dave对花俏的C++模板技巧的兴趣和娴熟刚好到了能真正做点什么的时候，Boost.Python就那样出现了，因为它满足了需求，因为它看起来挺酷，值得一试。

早期的版本针对的许多基本目标和在这篇论文中描述的相同。最显著的区别在于早期版本的语法要稍微麻烦一点，缺乏对操作符重载，pickling，基于组件的开发的专门支持。后面三个特性很快就被Ullrich Koethe和Ralf Grosse-Kunstleve [3] 加上了。其他热心的贡献者(contributors)也出来贡献了一些改进，如对嵌套模块和成员函数的支持等。

到2001年早期时开发已经稳定下来了，很少有新的特性添加，然而这时一个烦人的问题暴露出来了：Ralf已经开始在一个使用 EDG 前端的编译器的预发布版上测试Boost.Python，这时Boost.Python内核中负责处理Python和C++的类型转换的机制(mechanism)编译失败了。结果证明我们一直在利用一个bug，这个bug在所有我们测试过的C++编译器实现中都非常普遍。我们知道随着C++编译器很快变得更加标准兼容，库将开始在更多的平台上失败。很不幸，因为这套机制是库的功能的中枢，解决问题看起来非常困难。

幸运的是那一年的后期，Lawrence Berkeley和后来的Lawrence Livermore National labs和 Boost Consulting 签订了支持Boost.Python的开发的合同。这样就有了新的机会来处理库的基本问题，从而确保将来的发展。重新设计开始于低级类型转换架构，内置的标准兼容和对基于组件的开发的支持(和不得不显式的跨越模块边界导入或导出转换的第一版形成对比)。对Python和C++对象的关系进行了分析，从而能更直观的处理C++ lvalues和rvalues。

Python 2.2里出现的强大的新类型系统使得选择是否维护对Python 1.5.2的兼容性变得容易了：这个丢弃大量精心制作的仅仅用来模拟classic Python类的代码的机会，好的令人无法拒绝。另外，Python iterators 和 descriptors提供了重要且优雅的工具来描述类似的C++结构。一般化了的对象接口的开发允许我们进一步把C++程序员和使用Python C API带来的危险性和语法负担隔离开。大量的其他特性在这个阶段被加了进来，包括C++异常翻译，改进的重载函数支持，还有最重要的用来处理指针和引用的CallPolicies。

于2002年十月，第二版的Boost.Python发布了。那以后的开发集中在改进对C++运行时多态和智能指针的支持上。特别是Peter Dimov的巧妙的boost::shared_ptr设计使我们能给混和系统开发者提供一致的接口，用于跨越语言藩篱来回移动对象而不丢失信息。

刚开始，我们担心Boost.Python v2的复杂性会阻碍贡献者，但 Pyste 和几个其他重要特性的贡献(contribution)的出现使这些担心显得多余了。每天出现在Python C++-sig上的问题和希望得到的改进的积压(backlog)表明了库正在被使用。对我们来说，未来看起来很光明。

结论

Boost.Python 实现了两种功能丰富的优秀的语言环境间的无缝协作。因为它利用模板元编程技术来对类型和函数进行内省，用户永远用不着再学第三种语言:接口定义是用简洁而可维护的C++写的。同样，包装系统不用再解析C++头文件或是描述类型系统：编译器都给我们做了。

计算密集的任务适合强大的C++，它一般不可能用纯Python来实现。然而像序列化这样的工作，可能用Python很简单，用C++就非常困难。假如有从底层开始构建混合系统的奢侈，我们有新的信心和动力来进行设计。