-
Notifications
You must be signed in to change notification settings - Fork 627
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
Add typing.Result
and typing.ResultBatch
type variables
#4108
Conversation
Codecov Report
@@ Coverage Diff @@
## master #4108 +/- ##
=======================================
Coverage 99.76% 99.76%
=======================================
Files 345 345
Lines 30920 30934 +14
=======================================
+ Hits 30848 30862 +14
Misses 72 72
|
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.
Thanks, it looks good! A couple of minor comments
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.
Thanks Christina, this is coming along well. A few type hints need to be fixed, and I agree with @rmoyard 's suggestion about importing Result
and ResultBatch
from qml.typing
. rather than using qml.typing.Result
or qml.typing.ResultBatch
.
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.
Thanks!
Co-authored-by: Romain Moyard <rmoyard@gmail.com>
The results of an execution are difficult to concretely type hint due to the nested and dynamic shape of the object. Nonetheless, type hints are essential for clearly specific an interface and communicating what a function or method does.
pennylane.typing.Result
, atyping.TypeVar
specifies the result of a single execution.pennylane.typing.ResultBatch
, a tuple ofResult
, specifies the result of a batch of executions.I would prefer it if we could add documentation to a
TypeVar
, but at least this is an improvement and solves our current problem.This PR already adds the type hint to a couple of key places, mostly for the new device interface. As time goes on, we can improve coverage of type hints.