Designing an Python API: Fluent interface or arguments -


i'm playing around simple port of protovis api python.

consider simple bar chart example, in 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(); 

i'm debating whether continue use fluent interface style api or use named parameters instead. named parameters write:

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

is there preferred python style?

my vote anti-chaining, pro-named-params.

  1. dot-chaining makes poor code-intellisense since empirical prototype empty panel() or bar(), can of course pydoc on it, in day , age intellisense available in ides , great productivity booster.

  2. chaining makes programatically calling class more difficult. it's nice able pass in list or dict *args, **kwargs -- while possible chaining you'd have support both methods or bunch of backflips meta-create class.

  3. chaining makes code more difficult read because inevitably on 1 line, , wonder why things goofed when they've passed in same param twice -- can prevent named param constructor dup filtering built in.


Comments

Popular posts from this blog

ASP.NET/SQL find the element ID and update database -

jquery - appear modal windows bottom -

c++ - Compiling static TagLib 1.6.3 libraries for Windows -