Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

noemifrisina
Copy link
Contributor

@noemifrisina noemifrisina commented Apr 16, 2024

Allow the plans to only accept lists or tuples of hardware devices eg. detector to avoid unexpected behaviour.

Description

  • Adds a check on the type of the detector argument passed to the main plans used and raises an error if not a Sequence.
  • Adds type checking to plans and plan stubs.

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?

  • Type annotations should not change the functionality of the code.
  • Small additions to unit tests to verify that plans raise a TypeError if a generator is passed instead of a list.



#: Return type of a plan, usually None. Always optional for dry-runs.
P = TypeVar("P")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is duplicated.

Copy link
Contributor Author

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.

Comment on lines 94 to 114
#: 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]]
Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Contributor Author

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?

@noemifrisina
Copy link
Contributor Author

Docs build is failing because numpydocs doesn't accept having both Yields and Returns sections in the docstring. It seems it never has even in older versions and adding type hints may have triggered this check

@danielballan
Copy link
Member

Numpydoc PR to address this: numpy/numpydoc#542

@tacaswell
Copy link
Contributor

There is a numpydoc release now (which is why I tried to rebase #1610 because I thought that one was this one).

@danielballan
Copy link
Member

I see that @noemifrisina has CI passing. Were your concerns above adequately addressed, @callumforrester?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow plans to accept lazy iterables of detectors
4 participants