Widen trace_request_ctx type#9398
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #9398 +/- ##
=======================================
Coverage 98.57% 98.57%
=======================================
Files 107 107
Lines 35037 35037
Branches 4150 4150
=======================================
Hits 34536 34536
Misses 334 334
Partials 167 167
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Dreamsorcerer
left a comment
There was a problem hiding this comment.
Yeah, I was probably a little strict in this one, based on the limited uses in the tests. It's just a shame that you then don't get any type checking on your code, but probably a little complex to figure out something more accurate.
|
There's bound to be a way to explicitly declare the type of |
Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) <[email protected]>
I think I briefly looked at it when making these changes originally. I don't think the current API has a way to be able to connect that up, so it'd need some refactoring in future if someone wanted to figure that out. aiohttp-security has a similar issue, where the main API is separate from the class which defines the types, so there's no way to pass types through.. |
Backport to 3.10: 💚 backport PR created✅ Backport PR branch: Backported as #9403 🤖 @patchback |
Backport to 3.11: 💚 backport PR created✅ Backport PR branch: Backported as #9404 🤖 @patchback |
) **This is a backport of PR #9398 as merged into master (3f43bd1).** Co-authored-by: layday <[email protected]>
What do these changes do?
Widen the type of the
trace_request_ctxparameter ofClientSession.requestand friends.Are there changes in behavior for the user?
No.
Is it a substantial burden for the maintainers to support this?
No.
Related issue number
Fixes #9397.
Checklist
CONTRIBUTORS.txtCHANGES/foldername it
<issue_or_pr_num>.<type>.rst(e.g.588.bugfix.rst)if you don't have an issue number, change it to the pull request
number after creating the PR
.bugfix: A bug fix for something the maintainers deemed animproper undesired behavior that got corrected to match
pre-agreed expectations.
.feature: A new behavior, public APIs. That sort of stuff..deprecation: A declaration of future API removals and breakingchanges in behavior.
.breaking: When something public is removed in a breaking way.Could be deprecated in an earlier release.
.doc: Notable updates to the documentation structure or buildprocess.
.packaging: Notes for downstreams about unobvious side effectsand tooling. Changes in the test invocation considerations and
runtime assumptions.
.contrib: Stuff that affects the contributor experience. e.g.Running tests, building the docs, setting up the development
environment.
.misc: Changes that are hard to assign to any of the abovecategories.
Make sure to use full sentences with correct case and punctuation,
for example:
Use the past tense or the present tense a non-imperative mood,
referring to what's changed compared to the last released version
of this project.