Did we decide what to do about numpy arrays of doubles? Maybe those should still be converted? @Mike Miller what did you intend? (ideally, we would support something like COW for double arrrays---later!)
I know we can always bring back deleted code later, but for now let's try to be minimal about this change and only remove the logic that causes lists, dicts, and tuples to be converted automatically here.
I think keeping auto-conversion of Octave arrays into numpy arrays and back again is good to preserve, and we might still want the routines that convert to other types in the future.
@Mike Miller This is probably because octave_to_python converts it to numpy array and then python_to_octave converts it to octave list and not a pyobject. Should I remove the array conversion or let it be like this for now?
Sorry if there might have been noise (mails) as I forgot some minor changes in the PR a couple of times. I have now updated it to remove conversion of only lists, dicts and tuples to octave cell arrays.
The code that you removed in pyeval.cc has equivalent code in pycall.cc that you didn't remove (builtins_module, calculating the id, all now unused code).
Some equivalent tests could be added to pycall to do things like pycall ("list"), etc.
Also there are now a handful of failing tests in @pybobject methods due to this change. This is not a bad thing, these are things that should break, but you should get in the habit of running all of the tests when you make changes, and either fix tests that now break or point out what other changes will be necessary after this is merged. In this case it is mostly fieldnames and methods needing to adapt to the new return value convention.
So please file another PR that takes care of the housekeeping of removing the dead code from pycall.cc, and add some unit tests to pycall for list, dict, and tuple. These can be one commit or two separate commits in a single PR, either way you want to do it.