Diseñando una API de Python: Interfaces o argumentos fluidos

Question

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

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

estoy debatiendo si se debe continuar para utilizar este fluidez API estilo de interfaz o utilizar parámetros con nombre en su lugar. Con 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 anticadena, pro-named-params.

1. de puntos en cadena hace que para los pobres de código de IntelliSense ya que el prototipo empírica es sólo un panel vacío() o barra(), se puede, por pydoc supuesto en él, pero en este día y edad IntelliSense está disponible en la mayoría de los IDEs y un gran refuerzo de productividad.

2. El encadenamiento hace que programar la clase sea mucho más difícil. Es muy bueno poder pasar una lista o un dict como * args, ** kwargs: mientras sea posible con el encadenamiento, básicamente tendrías que admitir ambos métodos o un montón de backflips para metacrear la clase.

3. Encadenamiento hace que el código sea más difícil de leer porque inevitablemente alguien lo hará todo en una línea, y se preguntará por qué las cosas se complican cuando han pasado en el mismo parámetro dos veces - puede evitar eso pero con un named param constructor dup filter está básicamente integrado.