-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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 typings for Tracing #3343
Add typings for Tracing #3343
Conversation
aiohttp/tracing.py
Outdated
self, | ||
trace_config_ctx_factory: Type[SimpleNamespace]=SimpleNamespace | ||
) -> None: | ||
self._on_request_start = Signal(self) # type: Signal[Callable[['Application'], Awaitable[None]]] # noqa |
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.
Maybe define Signal[Callable[['Application'], Awaitable[None]]]
only once at top level and reuse it everywhere? You wouldn't need typing comments and qa disable in this case.
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.
Refactored
aiohttp/tracing.py
Outdated
from .client import ClientSession | ||
from .web_app import Application | ||
|
||
_Signal = Signal[Callable[[Application], Awaitable[None]]] |
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.
Please replace Application
with TraceConfig
to fix the signature
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.
done
self, | ||
trace_config_ctx_factory: Type[SimpleNamespace]=SimpleNamespace | ||
) -> None: | ||
self._on_request_start = Signal(self) # type: _Signal |
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.
Hm. Do we have any conventions about when to use type comment and when - annotation? Why not to use annotations everywhere? IIRC, those comments were made just for Python 2.x typing support.
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 didn't find any documented convention regarding style for annotations so it looks like the question to @asvetlov.
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.
- This comment is for Python 3.5;
a: type = val
is supported by Python 3.6 only. - We are in the middle of the transition to a fully annotated code. After the work is done mypy strict mode will be enabled.
The line is correct.
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 almost forgot what 3.5 is. Thanks!
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.
Looks good, can be merged on green CI checks
Thanks! |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a [new issue] for related bugs. |
What do these changes do?
Are there changes in behavior for the user?
Related issue number
#1749
Checklist
CONTRIBUTORS.txt
CHANGES
folder<issue_id>.<type>
for example (588.bugfix)issue_id
change it to the pr id after creating the pr.feature
: Signifying a new feature..bugfix
: Signifying a bug fix..doc
: Signifying a documentation improvement..removal
: Signifying a deprecation or removal of public API..misc
: A ticket has been closed, but it is not of interest to users.