Easy pickabability was a strong driver for this initial API.
disclosure: I work at Wallaroo Labs, creators of Wallaroo.
disclosure: I work at Wallaroo Labs, creators of Wallaroo.
def name(self):
return "split into words"
In my opinion, I think as much of this stuff should be done in a declarative way as possible.
We are looking for folks to help drive the next version of the API. The first one was done with feedback from a couple of clients who were interested in using Python and in many ways reflects their tastes. Feedback from a wider range of Python users is something we are actively soliciting at this point.
Likewise builder, just ask for a callable, and the smallest "builder" is the state class itself.
Computations seem similar, the APIDoc states they must provide a compute() method but the example shows only a compute_multi. Is there a use case for having both on the same object? If there isn't, just ask for a reduction function and provide a decorator for one of the use case. Or don't and always ask for a list of results.
Or handle the "multi" case via a generator I guess (call reducer, if it returns a generator run it and add all items to the processing queue, otherwise add the one item).