Enhancement: Python client Symbol cannot list a usage's inherited members (parts, ports, bindings), unlike attributes()

The issue names the Python client, children(), parts(), attributes(), and docs/reference/python-api.md; it also links pull request #1974, which is already open. Start by reviewing the linked pull request and the client API behavior described in the reproduction. Done means the API and docs clearly specify inherited members and address the reported behavior, including redefinitions and standard-library members.

This issue was written with AI help. The model, the reproduction script and its output are
attached and were run against the version below.

This is partly a feature request. The issue form points feature requests to Discussions, but
Discussions are not enabled on this repository, so it is filed as an issue.

What happened, and what you expected instead

A part definition declares a boundary port, a nested part and a named binding between them, and a
part usage in the system is typed by it:

part def Controller {
    attribute gain : ScalarValues::Real;
    port cmdIn : CmdPort;
    part logic : Logic;
    binding delegate bind cmdIn = logic.cmdIn;
}
part system {
    part controller : Controller;
}

Walking the system structure from Python, model.get("…::system::controller") gives:

Method	Returns
attributes()	['…::Controller::gain']: own and inherited, as its docstring says
parts()	[]: the inherited logic is missing
children()	[]: the inherited gain, cmdIn, logic and delegate are all missing

children() lists only the members the element itself declares (its owned members). For a usage
typed by a definition that is usually nothing, so a client that walks the structure through
usages, which is the natural way to walk an instance hierarchy, never sees the definition's ports,
parts or bindings. If one member is redefined (part tuned : Controller { attribute :>> gain = 2.0; }),
children() returns only that member.

Nothing documents this. children() says only "Return all child symbols", and parts() says
"Return child symbols that are part definitions or usages". Meanwhile attributes() on the same
object does include inherited members, so the two methods disagree about what belongs to the
element.

The service already has the inherited members. Through reflection,
last(system::controller.metadata).member starts with gain, cmdIn, logic, delegate, followed
by about 70 standard-library features. model.instantiate("…::system").controller has the
features cmdIn, delegate, gain and logic. The Symbol API is the only place that cannot
list them. The workaround is to fetch the definition (type_facts.resolved_id) and the targets of
specializations, then merge their children with the usage's own, applying redefinitions by
hand, which is the walk attributes() already does internally for attributes.

Requested:

1. A way to list a symbol's members own and inherited, as attributes() does for
   attributes. That could be children(inherited=True), a members() method, or inherited ids
   on SymbolInfo. It would follow the same rules as attributes(): a redefinition masks what it
   redefines, and standard-library members are left out and reported as withheld
   (withheld_library_attributes does this for attributes today).
2. parts() behaves like attributes() and includes inherited parts, or both are documented as
   different on purpose.
3. The docstrings of children() and parts() (and docs/reference/python-api.md) say whether
   inherited members are included.

Related: #1960 (children() also drops unnamed members of the element that declares them).

Reproduction

$ python repro_inherited.py      # loads inherited-model.sysml with opensysml.loads() over sysml-grpc
## The definition declares the members
[INFO] InheritedMembers::Controller.children()
       observed: [('attributeUsage', 'InheritedMembers::Controller::gain'), ('portUsage', 'InheritedMembers::Controller::cmdIn'), ('partUsage', 'InheritedMembers::Controller::logic'), ('bindingUsage', 'InheritedMembers::Controller::delegate')]

## The usage typed by it
[OK  ] InheritedMembers::system::controller is typed by InheritedMembers::Controller
[OK  ] InheritedMembers::system::controller.attributes() includes the inherited attribute (documented: own and inherited)
       observed: ['InheritedMembers::Controller::gain']
[BUG ] InheritedMembers::system::controller.parts() includes the inherited part 'logic'
       observed: []
       expected: ['InheritedMembers::Controller::logic']
[BUG ] InheritedMembers::system::controller: some Symbol method lists the inherited binding 'delegate'
       observed: []
       expected: ['InheritedMembers::Controller::gain', 'InheritedMembers::Controller::cmdIn', 'InheritedMembers::Controller::logic', 'InheritedMembers::Controller::delegate']

## A usage that redefines one member lists only that one
[INFO] InheritedMembers::system::tuned.children()
       observed: ['InheritedMembers::system::tuned::gain']

## The service does know the inherited members
[INFO] reflection: ownedMember (empty, as children())
       observed: []
[INFO] reflection: member (first four of the list; the rest are standard-library features)
       observed: ['gain', 'cmdIn', 'logic', 'delegate']
[INFO] instance: features of system.controller
       observed: ['cmdIn', 'delegate', 'gain', 'logic']

inherited-model.sysml:
package InheritedMembers {
    port def CmdPort {
        in attribute cmd : ScalarValues::Integer;
    }

    part def Logic {
        port cmdIn : CmdPort;
    }

    part def Controller {
        attribute gain : ScalarValues::Real;
        port cmdIn : CmdPort;                       // boundary port
        part logic : Logic;
        binding delegate bind cmdIn = logic.cmdIn;  // boundary-to-child binding, named
    }

    part system {
        part controller : Controller;               // usage typed by the definition
        part tuned : Controller {                   // the same, redefining one member
            attribute :>> gain = 2.0;
        }
    }
}

Reproduction files (attached)

File	Contents
model	inline above (no file attached): save it as inherited-model.sysml next to repro_inherited.py
repro_inherited.py	loads inherited-model.sysml with opensysml.loads() and compares children(), parts() and attributes() of the definition and the usages, then shows the same members through reflection and an instance. Each check prints OK, BUG or INFO, and the script exits 1 while any BUG reproduces.
output_inherited.txt	the full output of the run reported here
_common.py	shared helper the script imports: starts the sysml-grpc named by $OPENSYSML_BINARY, prints the server and client versions, and formats the checks

To run it, put _common.py in the parent directory of the folder holding repro_inherited.py and the model,
install the client (pip install -e client/python from an OpenSysML checkout), and point
OPENSYSML_BINARY at a sysml-grpc build:

$ OPENSYSML_BINARY=/path/to/OpenSysML/bin/sysml-grpc python repro_inherited.py

Without OPENSYSML_BINARY, _common.py assumes an OpenSysML checkout next to the directory
that holds _common.py, with bin/sysml-grpc built by make build-grpc.

_common.py

repro_inherited.py

output_inherited.txt

Version

sysml-grpc v0.12.0-262-gc86932321 (develop at c86932321), opensysml Python client 0.12.0, Python 3.13.15

Surface

Python client (opensysml)