Revisit Python-pony interface (Machida)

[nisanharamati]

Now that we have >1 year of experience with the Pony-Python interface under our belt, I think it's a good time to think about what's we would like to improve going forward (especially as the Python3 API approaches).

Some things worth looking at (feel free to edit this issue to add your own!)

• Use class type checks instead of attribute lookups for determining what type of computation is being executed (e.g. replace @PyObject_HasAttrString with PyObject_IsInstance etc.)
• Do we need the name() method? Can it be changed to an attribute?
• Is it possible to eliminate the computation class entirely and just execute the user defined function?
  • I believe in this case we would need to create some computation object in Pony instead to capture the metadata (maybe it's just a tuple with the name and a pointer to the python function,
• Any improvements we can make to error checkiing and handling?
• Machida shouldn't use Fail() in machida. Instead it should use FatalUserError or Unreachable with appropriate error messages.
• ??? (add your own here!)

/cc @WallarooLabs/wallaroo-labs

[caj-larsson]

I like the idea of removing the computation class and moving that structure into pony instead. But after trying out pickle on a function with added attributes I found that they don't get pickled. I guess that encode/decode functions can solve that if we also move this meta information into pony.

I've added a check to make sure that the users encode function either returns a bytes() or a unicode() compatible value. More type and value checks are definitely warranted in the action list parser.

We could also integrate with the optional typing in higher versions of python to disallow an explicit mismatch. However in runtime there is of course no way of making sure that we get the correct python types.