-
Notifications
You must be signed in to change notification settings - Fork 183
[v8.0] Annotate ReturnValues.py #6309
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
Conversation
1b283ce
to
bcf6ba0
Compare
b9749ac
to
a63a3f5
Compare
@@ -5,14 +5,43 @@ | |||
|
|||
keys are converted to string | |||
""" | |||
from __future__ import annotations |
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.
Why is this needed?
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.
It fixes a handful of annoying quirks when adding types. It was planned to be the default in 3.10 and then 3.11 but it has now been delayed twice due to having a different set of issues. PEP-649 has some more details but for now I think from __future__ import annotations
is the best course of action for DIRAC as it's more limited than the original approach. If we change our mind removing the future imports should be easier than the opposite approach.
Technically what it does it change the type hints to being evaluated on demand rather than at function definition time. For example:
class C:
@classmethod
def factory_func(cls) -> C:
return cls()
By default this fails with NameError: name 'C' is not defined
. Alteratively you can make the type hint a string which causes it's evaluation to be delayed:
class C:
@classmethod
def factory_func(cls) -> "C":
return cls()
But this is quite ugly and annoying and makes evaluating the type hints harder. Using from __future__ import annotations
makes it so that the type hint evaluation is always delayed. See [PEP-563](https://peps.python.org/pep-0563/ for details).
(Note this example isn't quite correct if you want correct typing for subclasses of C
.)
[tool.pylint.typecheck] | ||
# List of decorators that change the signature of a decorated function. | ||
signature-mutators = [] |
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.
Is this needed now? Are you just adding to not forget later 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.
I defer to @chaen
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.
if pylint
isn't complaining anymore, then we can remove it :-)
a63a3f5
to
d1d07c4
Compare
I originally just wanted to silent pylint for complaining about
unsubscriptable-object
when usingconvertToReturnValue
. Turns out to be trickier than expected: pylint-dev/pylint#7292Anyway, I added the type hints. Not sure whether we want to merge it already or wait for pylint to be fixed. I don't mind.
Also, as of python 3.10, we will be able to forward the type hint through the elipse https://peps.python.org/pep-0612/
Update from @cburr: This now adds type hints to the entire
ReturnValues
module and can propogate the type ofretVal["Value"]
throughS_OK
/convertToReturnValue
/returnValueOrRaise
. We can't actually use mypy for checking this until python/mypy#13389 is merged and releasd however I've tested locally with that branch and it works as expected and is able to catch a bunch of errors.Click me to see examples of errors than can now be caught with mypy
BEGINRELEASENOTES
*Core
NEW: Introduce DReturnType/DOKReturnType/DErrorReturnType for DIRAC return structures
ENDRELEASENOTES