3 ms·
Easy pickabability was a strong driver for this initial API. disclosure: I work at Wallaroo Labs, creators of Wallaroo.
by spooneybarger 9y ago
Easy pickabability was a strong driver for this initial API.
disclosure: I work at Wallaroo Labs, creators of Wallaroo.
- ericfrederich 9y agoStill doesn't seem very Pythonic. def name(self): return "split into words" Why isn't name a class attribute? Does this really need to be a callable function? In my opinion, I think as much of this stuff should be done in a declarative way as possible.
- spooneybarger 9y agoIf you'd be interested in playing with Wallaroo and providing feedback on a 2nd generation of the API, feel free to reach out via our IRC channel, user mailing list or ping me via my personal email address that is in my HN profile. 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.
- TremendousJudge 9y agoOr use the @property decorator
- masklinn 9y agoHaving to create a class called xPartitionFunction doesn't seem to favour easy pickability. Why isn't it just a function/callable? 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).