El diseño de una API de Python: interfaz fluida o argumentos

Question

Estoy jugando un poco con un simple puerto de la Protovis API para Python.

Considere el ejemplo gráfico de barras simple, en 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();

Me estoy debatiendo si se debe continuar para utilizar este fluidez API estilo de interfaz o utilizar parámetros con nombre en su lugar. Con los parámetros con nombre podríamos escribir:

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()

¿Hay un estilo preferido de Python?

Answer 1

Mi voto es anti-encadenamiento, pro-params con nombre.

1. dot-encadenamiento de marcas para pobres de código de IntelliSense ya que el prototipo empírica es sólo un panel vacío () o barra (), que puede de pydoc supuesto en él, pero en este día y edad IntelliSense está disponible en la mayoría IDE y un refuerzo de gran productividad.

2. El encadenamiento hace programáticamente llamar a la clase mucho más difícil. Es muy agradable ser capaz de pasar de una lista o dict como args *, ** kwargs - mientras que es posible con el encadenamiento que, básicamente, tendría que soportar ambos métodos o un montón de saltos mortales a meta-crear la clase

3. El encadenamiento hace que el código sea más difícil de leer porque, inevitablemente, alguien lo hará en una sola línea, y se preguntan por qué las cosas están metió la pata cuando que han pasado en el mismo parámetro dos veces - se puede evitar eso, pero con un constructor llamado parámetro de la duplicación de filtrado es básicamente construido en.