We are in the process of working with folks on a more "pythonic" API. Our first goal was to get something that would be easy to use out the door then get feedback on ideas we have for something more idiomatic to the language. It's an approach we plan to take when we add support for other languages such as Go and JavaScript over the next few months.

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.

disclosure: I work at Wallaroo Labs, creators of Wallaroo.

I'll be in touch. Best email please?

So python is the new ruby now.

Whatever that even means.

(Besides, Python has been popular longer than Ruby -- which only got big along with Rails' emergence).

I'm surprised you could even compare Python's current popularity (obviously due to machine learning libraries) with it's past popularity. Especially with all the comments you've been churning out on HN.

I've used Python professionally since 1999.

While Python found an extra niche with scientific libraries (and not just/especially machine learning) post numpy and co, it was already very popular then, taking the throne from Perl.

Ruby at the time (and until Rails) was seen as an interesting contester, but nobody doubted Python's top popularity as far as scripting goes.

P.S. What about "the comments I've been churning"? If you mean regarding P3 adoption, then we're still quite a long ways away. Not even 50% -- and well after 10+ years. But that's beside the point. That doesn't mean I don't like Python (including 3).

It's funny because the article's only mention of java is "Wallaroo isn’t built on the JVM, which provides advantages that we will cover in a later blog post."

Quickly followed by pointless Factory classes and classes implementing an interface with one method.

I guess the reason is that classes are picklable and functions, by default, are not? This is supposed to be a distributed system after all.

Easy pickabability was a strong driver for this initial API.

disclosure: I work at Wallaroo Labs, creators of Wallaroo.

Still 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.

If 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.

Or use the @property decorator

Having 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).

he should make a revised edition where they no longer consult the Sun God but rather the All Seeing Oracle...