Widen trace_request_ctx type

[layday]

What do these changes do?

Widen the type of the trace_request_ctx parameter of ClientSession.request and 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

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes
• If you provide code modification, please add yourself to CONTRIBUTORS.txt
  • The format is <Name> <Surname>.
  • Please keep alphabetical order, the file is sorted by names.
• Add a new news fragment into the CHANGES/ folder

  • name 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 an
      improper 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 breaking
      changes 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 build
      process.
    • .packaging: Notes for downstreams about unobvious side effects
      and 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 above
      categories.

  • Make sure to use full sentences with correct case and punctuation,
    for example:

    Fixed issue with non-ascii contents in doctest text files
    -- by :user:`contributor-gh-handle`.

    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.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.57%. Comparing base (25b67b6) to head (e4ab73d).
Report is 713 commits behind head on master.

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           

Flag	Coverage Δ
CI-GHA	98.45% <100.00%> (ø)
OS-Linux	98.11% <100.00%> (ø)
OS-Windows	96.53% <ø> (ø)
OS-macOS	97.80% <100.00%> (+<0.01%)	⬆️
Py-3.10.11	97.67% <100.00%> (ø)
Py-3.10.15	97.60% <100.00%> (ø)
Py-3.11.10	97.67% <100.00%> (ø)
Py-3.11.9	97.74% <100.00%> (-0.02%)	⬇️
Py-3.12.6	98.16% <100.00%> (ø)
Py-3.13.0-rc.3	98.15% <100.00%> (ø)
Py-3.9.13	97.56% <100.00%> (-0.01%)	⬇️
Py-3.9.20	97.50% <100.00%> (ø)
Py-pypy7.3.16	97.12% <100.00%> (ø)
VM-macos	97.80% <100.00%> (+<0.01%)	⬆️
VM-ubuntu	98.11% <100.00%> (ø)
VM-windows	96.53% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Dreamsorcerer]

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.

[layday]

There's bound to be a way to explicitly declare the type of trace_request_ctx on the ClientSession using type var defaults but that's probably an exercise for another day 😛

[Dreamsorcerer]

There's bound to be a way to explicitly declare the type of trace_request_ctx on the ClientSession using type var defaults but that's probably an exercise for another day 😛

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..

[patchback]

Backport to 3.10: 💚 backport PR created

✅ Backport PR branch: patchback/backports/3.10/3f43bd1b7d2b2630c2567d3620eaf886ad9e5184/pr-9398

Backported as #9403

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.

[patchback]

Backport to 3.11: 💚 backport PR created

✅ Backport PR branch: patchback/backports/3.11/3f43bd1b7d2b2630c2567d3620eaf886ad9e5184/pr-9398

Backported as #9404

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.