My present goal for pydrake is to provide Python wrappings of C++ Drake, prioritizing keeping the same API as C++, as I myself do not want to spend time at the moment developing a brand new API, and would prefer to use pydrake to prototype C++ behavior that, if it under performs in Python, can be more easily translated back to C++ given that the APIs are relatively similar.
At some point, it would be convenient to provide a Python API that is truer to Python, and is more user-friendly. Some goals:
More Pythonic in naming / API. Current naming conventions for C++ functionality stays true to C++ conventions; any new attributes / features (e.g. the Image[PixelType].data property) are written to be Pythonic (still not sure if that's a good thing...)
Reduce the type-specific hoops needed for working with the Systems framework (e.g. creating an RgbdCamera and querying images)
Other things...
(There were some discussions on slack about this, but since this came up in #8585 , wanted to make sure it's captured in an issue.)
My present goal for
pydrake
is to provide Python wrappings of C++ Drake, prioritizing keeping the same API as C++, as I myself do not want to spend time at the moment developing a brand new API, and would prefer to usepydrake
to prototype C++ behavior that, if it under performs in Python, can be more easily translated back to C++ given that the APIs are relatively similar.At some point, it would be convenient to provide a Python API that is truer to Python, and is more user-friendly. Some goals:
Image[PixelType].data
property) are written to be Pythonic (still not sure if that's a good thing...)RgbdCamera
and querying images)(There were some discussions on slack about this, but since this came up in #8585 , wanted to make sure it's captured in an issue.)
\cc @thduynguyen @ggould-tri @peteflorence