Approch to select tree of inheritance on inheritance_diagram

Hi,

I was playing around inheritance_diagram with the project i am working on (https://github.com/silx-kit/silx/pull/3053). Diagram is very useful so thanks for this project. I would like to know what you think about few points:

1. If there is a link between A and C between a private class _B (and the private flag in not set), the extension do not create a link between A and C. I think it would be good to draw A -> C. If you prefer it could be displayed with a dotted arrow, or with an intermediate anonymous class A -> [] -> C. What do you think?

2. When we specify a top classes, i expect to have only the inheritances (top-down) from that classes. But this extension also generate the whole inheritance of classes inheriting from the top class. I think it is noise, it is not the place to display this relationship.

Example

class A: pass
class B (A, Otherthing, Otherthing2): pass

With top class = A, the extension will also show Otherthing, Otherthing2.

3. BTW if i specify a top-class, classes inherited by this class with also be displayed. I don't think it is what you want.

4. A last small thing: It is based on syntactic class name. 2 classes with the same name will be merged together. Is it using python classes internally? Or is it based on text parsing?

To summarize I care about 2 use case for a documentation.

• In a specific class, you want to see how it is implemented, then you want to see the tree of classes inherited (bottom-up)
• In a package, you want to see all the implementations from a class (top-down). (use of top-classes?)

But it looks like this extension mix both, and i feel like the result will always be difficult to read, cause you do not ail the same thing. Is there a way to do one or the other of this approaches? Do you think it could be implemented?

Start by reviewing the inheritance_diagram extension and its handling of top-classes, private classes, and class-name identity. Clarify whether the goal is separate bottom-up and top-down diagrams, then define expected output for the examples before implementation; done means the selected behavior is documented and the reported cases are resolved.