Determine if an incremental-wrapping approach is possible or makes sense to make the server Python integration more Pythonic

[jmao-denver]

The core class in DH/PY integration is Table, it is used both in output and input in many of the sub-modules. This means wrapping it to make it more Pythonic could be a breaking change for the depending sub-modules without rewriting everything. We need to find out for sure if that's the case.

under Epic #1263

[jmao-denver]

The stated goal of the epic is to make the server side Python integration (the deephaven package) much more Pythonic, thus providing a better experience to the Python developers. A parallel goal is to make it as seamless as possible for a client side Python script to run on the server and vice versa. The latter requires we have an identical or very similar design of the Python API on both the server and the client.

After having carefully examining the current implementation of Python integration on the server side, I have come to realize that the scope of the work is quite a bit bigger than I first thought. These are the main reasons behind that realization. Some of these reasons especially 1, 2, also argue strongly against a partial effort.

1. io.deephaven.db.tables.Table is exposed at run-time via JPY, to wrap it in a hand-written Python class means that we need to wrap all the methods/functions that either return a Table object or receive one as an input. Otherwise, we will have two forms of ‘Table’ classes in the package, which is a nightmare none would want.
2. The code style and naming conventions of the current Python package are of Java’s and are not consistent with that of the new Python client which follows the Python styles and conventions. It’d be best that we just wrap up all the Java classes that need to be accessible from Python and make them all consistent in terms of code style and naming convention.
3. The documentation of the current Python package leaves a lot to be desired, as it is mostly generated from Java Doc, definitely not Pythonic with overloads and Java FQN all over the places. To make the documentation more Pythonic, we need to hand-craft proper Python docstrings and will probably have to wrap up a bit more Java classes than anticipated.
4. A properly written Python wrapper of a Java class will also need to take care of data type mappings between Python and Java beyond what JPY offers.
5. A JPY runtime exposed class makes avaiable all its public methods and members, a wrapper of it might need to do some curation work on those.
6. The final hand-written Python package should also have a consistent Pythonic error handling strategy, this is something the current one has overlooked.
7. Technical debt in the current Python package: misplaced functions, not-so-coherent content structure, and other questionable decisions means we need to do some good reorganization.
8. A more comprehensive test suite would be nice for the new Python package. The current one can afford having minimal test cases because its directly-mapped nature and that the mapped engine Java classes should have adequate test coverage already. The new can still enjoy the same benefit but with additional Python code, it'd be best that we have a proper test suite.
9. Current DHCC documentation/examples need to be checked against the rewritten package and updated accordingly.
10. My lack of experience with some of the features in the current package beyond table operations will be a factor in how fast the project can move.

[jmao-denver]

@rcaudy reviewed the comments and agreed with most of them. The parent epic will be my next big priority. As this is going to be a long project, we will need to break the epic into properly sized deliverables. More tickets are coming.