Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upIntroduce mypy stub for typeguard, and type-check parsl.load() #874
Conversation
benclifford
changed the title
Introduce mypy stub for enforce.py, and type-check parsl.load()
[don't merge yet] Introduce mypy stub for enforce.py, and type-check parsl.load()
Apr 14, 2019
This comment has been minimized.
This comment has been minimized.
i'd like #875 merged, and this pr updated for that first |
This allows mypy to understand the type signatures of functions decorated with @typeguard.typechecked, allowing the type signatures on such functions to be used by both enforce and mypy. Prior to this commit, adding @TypeChecked removed the ability of mypy to type-check calls to decorated functions, as it did not understand that the type of such a decorated function is the same as the original function. The added stub makes this declaration. The test-suite mypy calls are modified to use that stub file. The immediate motivation for this is to keep mypy passing when adding a type annotation for parsl.load; that type annotation is also added in this commit. This commit fixes some of problem described in the commit message for d7d9a25 about breaking mypy type checking for end user Configs in some places, but by no means all of it. However there is a mypy bug, python/mypy#5398, where decorated __init__ methods are not properly type-checked by mypy, which means that mypy typechecking is still missing on any decorated __init__ methods - which unfortunately is most of the user-facing type checked code. At time of writing, there are PRs open to fix this in mypy, so there is hope; and that does not impede this PR being merged.
benclifford
force-pushed the
benc-enforce-vs-mypy
branch
3 times, most recently
from
Apr 15, 2019
9a20485
to
ecaa0ac
benclifford
changed the title
[don't merge yet] Introduce mypy stub for enforce.py, and type-check parsl.load()
Introduce mypy stub for enforce.py, and type-check parsl.load()
Apr 15, 2019
benclifford
changed the title
Introduce mypy stub for enforce.py, and type-check parsl.load()
Introduce mypy stub for typeguard, and type-check parsl.load()
Apr 15, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
benclifford commentedApr 14, 2019
•
edited
Introduce mypy stub for typeguard, and type-check parsl.load()
This allows mypy to understand the type signatures of functions
decorated with @typeguard.typechecked, allowing the type signatures
on such functions to be used by both enforce and mypy.
Prior to this commit, adding @typeguard.typechecked removed the ability of mypy to
type-check calls to decorated functions, as it did not understand that
the type of such a decorated function is the same as the original
function. The added stub makes this declaration.
The test-suite mypy calls are modified to use that stub file.
The immediate motivation for this is to keep mypy passing when adding a
type annotation for parsl.load; that type annotation is also added in
this commit.
This commit fixes some of problem described in the commit message for
d7d9a25 about breaking mypy type checking for end user Configs in some
places, but by no means all of it.
However there is a mypy bug, python/mypy#5398,
where decorated init methods are not properly type-checked by mypy,
which means that mypy typechecking is still missing on any decorated
init methods - which unfortunately is most of the user-facing type
checked code.
At time of writing, there are PRs open to fix this in mypy, so there
is hope; and that does not impede this PR being merged.