bluesky / ophyd

hardware abstraction in Python with an emphasis on EPICS
https://blueskyproject.io/ophyd
BSD 3-Clause "New" or "Revised" License
50 stars 79 forks source link

Add flag and rework `walk_*` methods. #752

Open danielballan opened 5 years ago

danielballan commented 5 years ago

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:

Examples:

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).

klauer commented 5 years ago

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.

danielballan commented 5 years ago

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

klauer commented 3 years ago

Should we get a better label on this issue?