Skip to content
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

[PR #10154/3f07b1a3 backport][3.11] Update StreamResponse.write annotation for strict-bytes #10157

Conversation

patchback[bot]
Copy link
Contributor

@patchback patchback bot commented Dec 11, 2024

This is a backport of PR #10154 as merged into master (3f07b1a).

What do these changes do?

Mypy will add a --strict-bytes flag. python/mypy#18263

With that bytearray and memoryview are no longer subclasses of bytes and must be listed explicitly instead if they are supported.

Are there changes in behavior for the user?

--

Related issue number

--

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.

## What do these changes do?
Mypy will add a `--strict-bytes` flag.
python/mypy#18263

With that `bytearray` and `memoryview` are no longer subclasses of
`bytes` and must be listed explicitly instead if they are supported.

## Are there changes in behavior for the user?
--

## Related issue number
--

## 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 &lt;Name&gt; &lt;Surname&gt;.
  * 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:
    ```rst
    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.

---------

Co-authored-by: J. Nick Koston <nick@koston.org>
(cherry picked from commit 3f07b1a)
Copy link

codspeed-hq bot commented Dec 11, 2024

CodSpeed Performance Report

Merging #10157 will not alter performance

Comparing patchback/backports/3.11/3f07b1a38beffc350adbf51a605d27fe306de66c/pr-10154 (395fe83) with 3.11 (b770b1a)

Summary

✅ 47 untouched benchmarks

Copy link

codecov bot commented Dec 11, 2024

❌ 1 Tests Failed:

Tests completed Failed Passed Skipped
3465 1 3464 99
View the top 1 failed tests by shortest run time
tests.test_web_runner test_runner_setup_without_signal_handling[pyloop]
Stack Traces | 0.216s run time
make_runner = <function make_runner.<locals>.go at 0x000000000dcecca0>

    #x1B[0m#x1B[37m@pytest#x1B[39;49;00m.mark.skipif(#x1B[90m#x1B[39;49;00m
        platform.system() == #x1B[33m"#x1B[39;49;00m#x1B[33mWindows#x1B[39;49;00m#x1B[33m"#x1B[39;49;00m, reason=#x1B[33m"#x1B[39;49;00m#x1B[33mthe test is not valid for Windows#x1B[39;49;00m#x1B[33m"#x1B[39;49;00m#x1B[90m#x1B[39;49;00m
    )#x1B[90m#x1B[39;49;00m
    #x1B[94masync#x1B[39;49;00m #x1B[94mdef#x1B[39;49;00m #x1B[92mtest_runner_setup_without_signal_handling#x1B[39;49;00m(make_runner: Any) -> #x1B[94mNone#x1B[39;49;00m:#x1B[90m#x1B[39;49;00m
        runner = make_runner(handle_signals=#x1B[94mFalse#x1B[39;49;00m)#x1B[90m#x1B[39;49;00m
        #x1B[94mawait#x1B[39;49;00m runner.setup()#x1B[90m#x1B[39;49;00m
>       #x1B[94massert#x1B[39;49;00m signal.getsignal(signal.SIGTERM) #x1B[95mis#x1B[39;49;00m signal.SIG_DFL#x1B[90m#x1B[39;49;00m
#x1B[1m#x1B[31mE       assert <function Proxy._handle_exit_signal at 0x000000000f156700> is <Handlers.SIG_DFL: 0>#x1B[0m
#x1B[1m#x1B[31mE        +  where <function Proxy._handle_exit_signal at 0x000000000f156700> = <function getsignal at 0x0000000000e09100>(<Signals.SIGTERM: 15>)#x1B[0m
#x1B[1m#x1B[31mE        +    where <function getsignal at 0x0000000000e09100> = signal.getsignal#x1B[0m
#x1B[1m#x1B[31mE        +    and   <Signals.SIGTERM: 15> = signal.SIGTERM#x1B[0m
#x1B[1m#x1B[31mE        +  and   <Handlers.SIG_DFL: 0> = signal.SIG_DFL#x1B[0m

make_runner = <function make_runner.<locals>.go at 0x000000000dcecca0>
runner     = <aiohttp.web_runner.AppRunner object at 0x0000000009c36e58>

#x1B[1m#x1B[31mtests/test_web_runner.py#x1B[0m:57: AssertionError

To view more test analytics, go to the Test Analytics Dashboard
📢 Thoughts on this report? Let us know!

@asvetlov asvetlov merged commit 7f38913 into 3.11 Dec 11, 2024
36 checks passed
@asvetlov asvetlov deleted the patchback/backports/3.11/3f07b1a38beffc350adbf51a605d27fe306de66c/pr-10154 branch December 11, 2024 14:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants