-
Notifications
You must be signed in to change notification settings - Fork 109
Only allow plans to accept Sequences of detectors #1712
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Only allow plans to accept Sequences of detectors #1712
Conversation
…13_allow-only-sequences-in-plans
src/bluesky/utils/__init__.py
Outdated
|
||
|
||
#: Return type of a plan, usually None. Always optional for dry-runs. | ||
P = TypeVar("P") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is duplicated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, leftover from merge conflict. Removed now.
src/bluesky/utils/__init__.py
Outdated
#: Return type of a plan, usually None. Always optional for dry-runs. | ||
P = TypeVar("P") | ||
|
||
#: Object usually returned from plan functions that is fed to the RunEngine | ||
MsgGenerator = Generator[Msg, Any, Optional[P]] | ||
|
||
#: Metadata passed from a plan to the RunEngine for embedding in a start document | ||
CustomPlanMetadata = Dict[str, Any] | ||
|
||
|
||
#: Return type of a plan, usually None. Always optional for dry-runs. | ||
P = TypeVar("P") | ||
|
||
#: Object usually returned from plan functions that is fed to the RunEngine | ||
MsgGenerator = Generator[Msg, Any, Optional[P]] | ||
|
||
#: Metadata passed from a plan to the RunEngine for embedding in a start document | ||
CustomPlanMetadata = Dict[str, Any] | ||
|
||
#: Scalar or iterable of values, one to be applied to each point in a scan | ||
ScalarOrIterableFloat = Union[float, TypingIterable[float]] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this (or some of it) should live in protocols.py
as a more useful public API, @mrakitin may have thoughts
src/bluesky/tests/test_plans.py
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May already be covered, but if not could do with a test to make sure we can pass a list and tuple. Also a copy/paste job of the count test for the other plans would be ideal, but can be turned into a separate issue if you want to move on
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not completely covered I'd say, all the tests pass lists to the plans but no tuples. Is it worth adding a small test passing both or would changing some of the existing ones to pass tuples be enough?
Co-authored-by: Callum Forrester <[email protected]>
Co-authored-by: Callum Forrester <[email protected]>
Docs build is failing because |
Numpydoc PR to address this: numpy/numpydoc#542 |
There is a numpydoc release now (which is why I tried to rebase #1610 because I thought that one was this one). |
I see that @noemifrisina has CI passing. Were your concerns above adequately addressed, @callumforrester? |
Callum is on Zoom and is happy with the conclusion here.
Allow the plans to only accept lists or tuples of hardware devices eg. detector to avoid unexpected behaviour.
Description
detector
argument passed to the main plans used and raises an error if not a Sequence.Pulled in PR#1610 which had started the work on type checking.
Note, should be merged after #1701 as python 3.8 mypy tests will fail in CI.
Motivation and Contex
Currently plans will still run to completion if passed an iterable different from a generator as input, but will do the wrong thing in the background.
Fixes #1613 .
How Has This Been Tested?