This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
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.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add type annotations to
synapse.metrics
#10847Add type annotations to
synapse.metrics
#10847Changes from 5 commits
66d63c0
934fe41
f058e4f
dbe4345
949439c
d55eb93
ab66469
d1ee5da
6924ce8
7ab1153
77120c2
dba3f61
b483e31
dd276d1
055dbde
b7d099b
6c2f682
53ff8f5
550d1bc
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 think this should work, but maybe not? This makes me a bit nervous that we're not mentioning this returns a
Deferred
.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 sure what to do about this. I updated the docstring above to call the change of return type out.
We can either annotate the return type correctly and lose the types of the arguments for the decorated function,
or annotate the return type incorrectly and preserve the types of the arguments.
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 feel kind of bad about lying but appreciate the dilemma. :/
I'm not really sure what's best, though. Is lying going to cause type errors for users of the function?
I would probably make the docstring louder about the return type being a lie, though.
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 tried to improve the docstring further
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 think it's fine as - is.
question though, what happens if you bound
F
to return an Awaitable?F = TypeVar("F", bound=Callable[..., Awaitable])
(or something similar?)
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.
to be clear: I'm saying I'm happy with the PR as it stands.
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.
Ooh. mypy throws up 3 errors which all look trivial to fix:
So it sounds like the cleanest thing to do is to restrict
run_as_background_process
to only acceptAwaitable
-returning functions and drop the wholemaybe_awaitable
thing. I'll make the change when I find some time.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've gotten rid of the
maybe_awaitable
.