Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

py systems: Unable to downcast System to known intermediate type (e.g. Diagram) #13298

Closed
EricCousineau-TRI opened this issue May 13, 2020 · 1 comment
Assignees
Labels
component: pydrake Python API and its supporting Starlark macros priority: low type: bug

Comments

@EricCousineau-TRI
Copy link
Contributor

EricCousineau-TRI commented May 13, 2020

I'm sure this is a known issue, but doesn't look like it's already covered here:
https://pybind11.readthedocs.io/en/stable/classes.html#inheritance-and-automatic-downcasting

Issue

Basically, if you have a type, say class MyDiagram : public Diagram<double>, that you add within a nested hierarchy of diagrams via DiagramBuilder, and then you want to hack-debug this (e.g. add a printer in Python which just digs out the system, calls GetMyContextFromRoot, and evaluate ports), you can kind of do this, if you only need the ports.

However, if you need Diagram functionality (like GetSubsystemByName) from an API that only returns System (e.g. DiagramBuilder.AddSystem), it won't work.
Since pybind11 doesn't know about MyDiagram, it doesn't know about intermediate bases, so it can only downcast to System.

Use Case

For example, I'd love to write a Python script which just crawls the overall structure and give me direct pointers to systems.
I can see a structure from GraphViz, but I'd like to easily dig in as well.
AFAIK, this isn't currently possible in pydrake.

Repro

EricCousineau-TRI@09b73385e4

Workaround

For specific things, like crawling around the full structure of nested diagrams in Python, it'd be nice to have a as_diagram() method which attempts to cast the System_[T] to Diagram_[T], or returns None if it fails.

@EricCousineau-TRI EricCousineau-TRI added priority: low component: pydrake Python API and its supporting Starlark macros labels May 13, 2020
@EricCousineau-TRI EricCousineau-TRI self-assigned this May 13, 2020
@EricCousineau-TRI
Copy link
Contributor Author

I believe this came up in some of @rwgk's investigation here:
pybind/pybind11#2672
More specifically, he noted that this setup in Boost.Python may allow for exposing "skips" in exposed inheritance:
https://github.com/boostorg/python/blob/5e4f6278e01f018c32cebc4ffc3b75a743fb1042/src/object/inheritance.cpp#L390

@jwnimmer-tri jwnimmer-tri closed this as not planned Won't fix, can't repro, duplicate, stale Mar 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: pydrake Python API and its supporting Starlark macros priority: low type: bug
Projects
None yet
Development

No branches or pull requests

2 participants