ophyd icon indicating copy to clipboard operation
ophyd copied to clipboard

Add flag and rework `walk_*` methods.

Open danielballan opened this issue 6 years ago • 3 comments

The addition of the walk_* methods into ophyd:

$ git grep "def walk_"
ophyd/device.py:    def walk_signals(self, *, include_lazy=False):
ophyd/device.py:    def walk_subdevices(self, *, include_lazy=False):

[edited to remove classmethods]

prompted a long-running discussion about how different the Device and Signal abstraction in ophyd are and in what ways we should expose those differences. In an in-person discussion between @klauer, @tacaswell, and me, we found this consensus:

  • Device and Signal can be used identically.
  • You are allowed to know whether a given {Device or Signal} is a "Network Leaf Node", which is the most granular thing you can send messages to or, equivalently, parallelize I/O over.
  • You are allowed to know whether a given {Device or Signal} has structure.

Examples:

  • A Device has structure. It is not a "network leaf node" because it does no communication; communication is fanned out through its children.
  • An EpicsSignal has not structure. It is an network leaf node.
  • The hypothesized "TangoSignal" would have structure and would also be a network leaf node.

In recognition of this, we proposed to add one new IntFlag to all Signal and Device classes that denotes whether they have structure and whether they are network leaf nodes. The walk_* methods (which have not yet been in any ophyd release) would be removed and replaced by one method, walk(flag_mask, depth).

danielballan avatar Aug 12 '19 17:08 danielballan

Good summary of the discussion, @danielballan.

The only thing that sticks out that we didn't really discuss is the difference between the classmethod walk* and the instancemethod walk* - and I'm assuming the proposed walk_flag solution would only apply to the latter.

I personally think there's value in retaining the ability to introspect devices prior to instantiation. Were this to extend to the hypothetical TangoSignal, there would have to be a flag that indicated dynamic_structure as the flags could not be determined prior to connecting. And the dynamically-generated proxy components allowing access to that structure would not yet exist.

klauer avatar Aug 12 '19 17:08 klauer

Agreed. Dumping the git grep output above without comment was slapdash. The classmethods seem fine as is to me.

danielballan avatar Aug 12 '19 17:08 danielballan

Should we get a better label on this issue?

klauer avatar Mar 23 '21 14:03 klauer