compute API changes

[kwmsmith]

@postelrich @llllllllll here's my proof-of-concept for the compute() API changes. It's messy, and some of the imports will have to change, and we'll need some small refactoring, but I like that it doesn't require huge code changes, and fits in with the existing compute implementation easily.

Example usage:

In [26]: s = bz.symbol('s', 'var * {name: string, id: int}')

In [27]: t = bz.symbol('t', 'var * {name: string, a: int}')

In [28]: sdata = [['a', 1], ['b', 2]]

In [29]: tdata = [['a', 5], ['c', 7]]

The default gives back a list as one would expect:

In [30]: bz.compute(bz.join(s, t, 'name', how='outer'), {s: sdata, t: tdata})
Out[30]: [('a', 1, 5), ('c', None, 7), ('b', 2, None)]

And the return type can be easily overridden:

In [31]: bz.compute(bz.join(s, t, 'name', how='outer'), {s: sdata, t: tdata}, return_type=pd.DataFrame)
Out[31]:
  name  id   a
0    a   1   5
1    c NaN   7
2    b   2 NaN

In [32]: bz.compute(bz.join(s, t, 'name', how='outer'), {s: sdata, t: tdata}, return_type=np.ndarray)
Out[32]:
array([('a', 1.0, 5.0), ('c', nan, 7.0), ('b', 2.0, nan)],
      dtype=[('name', 'O'), ('id', '<f4'), ('a', '<f4')])

[llllllllll]

do we need the changes in here?

[kwmsmith]

@llllllllll agreed on your comments, and if we go with this approach, we'll definitely make those improvements. This is just a quick and dirty POC to demonstrate the API I'm thinking of, and how it can be implemented without a major rename or big refactoring.

What are your thoughts on the API?

[llllllllll]

I like the API. I would like to be able to register new return types like discussed in the other issue but for a first pass this looks great.

[sandhujasmine]

+1, it looks good.

• returning results is a more intuitive response from compute()
• list output by default makes sense for SQLA backends
• being able to override output return_type is a good idea

[kwmsmith]

@llllllllll will be merging this in the next day or so, last call.

[llllllllll]

No other comments, thanks!