设计 Python API：流畅的接口或参数答案

【问题标题】：Designing an Python API: Fluent interface or arguments设计 Python API：流畅的接口或参数
【发布时间】：2010-10-07 16:50:39
【问题描述】：

我正在使用Protovis API 到 Python 的简单端口。

考虑简单的条形图示例，在 Javascript 中：

var vis = new pv.Panel()
    .width(150)
    .height(150);

vis.add(pv.Bar)
    .data([1, 1.2, 1.7, 1.5, .7, .3])
    .width(20)
    .height(function(d) d * 80)
    .bottom(0)
    .left(function() this.index * 25);

vis.render();

我正在争论是继续使用这种流畅的界面风格 API 还是使用命名参数。使用命名参数我们可以这样写：

vis = pv.Panel(width=150,
               height=150)

vis = vis + pv.Bar(data=[1, 1.2],
                   width=20,
                   height=lambda d: d * 80,
                   bottom=0,
                   left=lambda: self.index * 25)
vis.render()

有首选的 Python 风格吗？

【问题讨论】：

有趣。两个我都见过。例如Django 同时使用：方法链和关键字参数。
也许只有我一个人，但我认为这两者都很丑：P
关键字语法的优点是你可以使用pv.Bar(**kwargs) 之类的东西比使用流畅的API 更容易。此外，正如我在带有 jQuery 的 JavaScript 中看到的那样，使用了很多匿名函数——这些函数不能很好地映射到 Python。

标签： python interface-design

【解决方案1】：

我的投票是反链接，支持命名参数。

点链会导致代码智能感知不佳，因为经验原型只是一个空的 Panel() 或 Bar()，您当然可以在其上使用 pydoc，但在当今时代，智能感知在大多数情况下都可用IDE 和强大的生产力助推器。
链接使得以编程方式调用类变得更加困难。能够将列表或字典作为 *args、**kwargs 传递是非常好的——虽然可以使用链接，但您基本上必须支持这两种方法或一堆后空翻来元创建类。
链接使代码更难阅读，因为不可避免地有人会在一行中完成所有操作，并且想知道为什么当它们两次传递同一个参数时事情都搞砸了——你可以防止这种情况，但使用基本上内置了一个命名参数构造函数 dup 过滤。

【讨论】：