Open EricCousineau-TRI opened 5 years ago
I think it would be fine to invent a totally new Python API for "I want to write a simple, pure-python System with as little boilerplate as possible" that diverges from the C++ VectorSystem API. (Keeping around the APIs that still make sense is fine, to avoid user-code churn.)
For one, because that there is some debate that C++ VectorSystem should live on in the first place (#10348).
But really, the intent of VectorSystem is to make C++ sugar for common C++ use cases. There will be tradeoffs there that don't make sense for Python. I'd rather than Python get the best possible sugar / deboilerplating, than that we wed it to C++ VectorSystem.
~I don't really think there's a solution to this, pending a novel API rewrite.~ I believe the sugar Jeremy alluded to could be prototyped using the current bindings, but I'm not sure if I'm the right person as I prefer the explicit C++ API parity, because that makes transcribing that much clearer.
Reassigning to you, Jeremy. Feel free to reassign if you feel there's someone better suited.
Given that I did some stuff on function_system.py
a ways back, will re-own this:
https://github.com/EricCousineau-TRI/repro/tree/54494a5c5154f19e693e4862fbaa79cddcd78d6f/drake_stuff/drake_py_meta
Not planning on tackling this any time soon, tho.
Moved from #10745:
@RussTedrake wrote:
I would still like to maintain the design philosophy that the Python bindings shouldn't diverge too far from the C++ bits, unless there is meaningful sugar (in which case, there should be minimal interface coupling via forwarding).
To that end, possible solution routes: