Open danielballan opened 6 years ago
P.S. Tangentially related is this two-year-old issue in ophyd: https://github.com/NSLS-II/ophyd/pull/241. See this comment in particular for why OrStatus
didn't get merged. AndStatus
was later merged in a different PR.
wait_any
sounds very useful.
Nice catch about the groups idea. Indeed, one may want to wait for a group, then find the finished element in the group, and wait again with a smaller subset. Static groups don't let that happen.
I'm not so experienced with bluesky but I definitely see these things being useful you've mentioned :-)
wait_any
messagestatus1 | status2
for ex. but wait_any
(and maybe other messages) might obviate this one.
It would be useful to be able to express "wait for any of the status objects in this group to complete". Here is an example that is annoyingly convoluted and could be made simpler with 'wait_any':
See this gist for the original and implementation of
OrStatus
.If we had 'wait_any' command, we could replace the troubling code block with:
This raises another issue. The RunEngine expects us to assign each status object to one group at creation time and then address those status objects indirectly via their group labels (in this example,
'foo'
). At the very beginning, when we sort of imagined users writings thing like:that seemed more convenient than
With more perspective, we know that users are rarely acting that this low of a level. I wonder if handling the status objects directly might actually be better. What if I want to wait for different "groups" of status objects at different points in the plan? Groups don't let me do that.
What if
Msg('wait', ...)
andMsg('wait_any', ...)
accepted groups or status objects? I don't think we explicitly require groups to be strings (they can be any hashable object) but in practice they always are. This change could therefore be made in a non-breaking way: if theMsg
has a string, that's a group; if theMsg
has some other Iterable, treat them as status objects.