Skip to content

Bump mypy from 2.3.0 to 2.3.1 - #2264

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/pip/mypy-2.3.1
Open

Bump mypy from 2.3.0 to 2.3.1#2264
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/pip/mypy-2.3.1

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Aug 19, 2026

Copy link
Copy Markdown
Contributor

Bumps mypy from 2.3.0 to 2.3.1.

Changelog

Sourced from mypy's changelog.

Mypy 2.3.1

  • Fix mypyc crash on double yielding Iterators (Daniël van Noord, PR 21826)
  • Fix mypyc default_factory for inherited dataclass (Daniël van Noord, PR 21785)
  • Clear mypyc coroutine env on coroutine completion (Piotr Sawicki, PR 21734)
  • Fix crash when unpacking return value from overload (Shantanu, PR 21830)

Acknowledgements

Thanks to all mypy contributors who contributed to this release:

  • Agriya Khetarpal
  • Ethan Sarp
  • Ivan Levkivskyi
  • Jingchen Ye
  • Jukka Lehtosalo
  • Piotr Sawicki
  • Shantanu
  • Tom Bannink
  • Viktor Szépe
  • ygale

I'd also like to thank my employer, Dropbox, for supporting mypy development.

Mypy 2.2

We've just uploaded mypy 2.2.0 to the Python Package Index (PyPI). Mypy is a static type checker for Python. This release includes new features, performance improvements and bug fixes. You can install it as follows:

python3 -m pip install -U mypy

You can read the full documentation for this release on Read the Docs.

Support for Closed TypedDicts (PEP 728)

Mypy now supports closed TypedDicts as specified in PEP 728. A closed TypedDict cannot have extra keys beyond those explicitly defined. This allows the type checker to determine that certain operations are safe when they otherwise wouldn't be due to the potential presence of unknown keys.

You can use the closed keyword argument with TypedDict:

HasName = TypedDict("HasName", {"name": str})
HasOnlyName = TypedDict("HasOnlyName", {"name": str}, closed=True)
Movie = TypedDict("Movie", {"name": str, "year": int})
movie: Movie = {"name": "Nimona", "year": 2023}
has_name: HasName = movie  # OK: HasName is open (default)
has_only_name: HasOnlyName = movie  # Error: HasOnlyName is closed and Movie has extra "year" key
</tr></table>

... (truncated)

Commits

Most Recent Ignore Conditions Applied to This Pull Request
Dependency Name Ignore Conditions
mypy [>= 1.17.dev0, < 1.18]

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Bumps [mypy](https://github.com/python/mypy) from 2.3.0 to 2.3.1.
- [Changelog](https://github.com/python/mypy/blob/master/CHANGELOG.md)
- [Commits](python/mypy@v2.3.0...v2.3.1)

---
updated-dependencies:
- dependency-name: mypy
  dependency-version: 2.3.1
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file python Pull requests that update Python code labels Aug 19, 2026
@claude

claude Bot commented Aug 19, 2026

Copy link
Copy Markdown

Review

This is a routine Dependabot patch bump: mypy 2.3.0 → 2.3.1 in requirements/local.txt (dev-only dependency, one line changed).

  • Code quality / bugs: N/A — no application code is touched.
  • Security: No security-relevant changes; mypy is a dev-time static type checker, not a runtime/production dependency, so no attack surface changes. The changelog notes are all mypyc crash fixes, unrelated to security.
  • Performance: No impact expected.
  • Test coverage: N/A — nothing to test. Worth confirming CI's mypy/typecheck step still passes cleanly with the new version (occasionally a mypy patch release tightens inference and surfaces new type errors), but nothing in the diff suggests a problem.

No concerns — safe to merge once CI is green.

JSv4 added a commit that referenced this pull request Aug 20, 2026
…ired

`main`'s branch protection has no `required_status_checks` object at all, so
nothing gates a merge on CI having run, let alone passed. PR #2262 merged with
Backend CI never having run on its head commit at all -- and because nothing
was required, "no check reported" was not a blocker. The push that merged it
then failed at the linter, which skipped `pytest` (0s); `main` sat that way for
~30 hours, repaired only by accident when an unrelated PR's
`pre-commit run --all-files` happened to reformat the same file.

Requiring *something* is therefore the fix, but requiring the `pytest` job is
not, because it leaves a second hole open and opens a third:

  * GitHub reports a job skipped by its own `if:` as SUCCESS to branch
    protection. `pytest` is gated on `needs.linter.result == 'success'`, so a
    red linter skips it and a required `pytest` still reads green. This is not
    hypothetical: PRs #2260, #2264 and #2265 are all sitting at
    `linter=failure / pytest=skipped` right now, and would be mergeable under
    that policy with a red linter.
  * A workflow skipped by path filtering never reports its checks at all, so
    the required check hangs Pending forever. With `paths-ignore: docs/**` on
    the `pull_request` trigger, requiring any job here would make docs-only
    PRs permanently unmergeable.

So the requirable check has to always run and inspect the other jobs itself,
telling "skipped because this PR touches no backend code" apart from "skipped
because something upstream broke". That is the new `gate` job; its decision
table is `.github/scripts/backend_ci_gate.sh`, which carries a `--self-test`
that the job runs on every invocation -- a gate whose own logic has silently
inverted is worse than no gate.

`paths-ignore` is dropped from the `pull_request` trigger for the reason
above; the `changes` path filter still keeps the expensive jobs from running,
so a docs-only PR now costs two ubuntu-latest jobs of a few seconds.

`require_backend_ci_gate.sh` applies the protection change itself, because the
obvious `gh api` call is a footgun: `PUT .../branches/main/protection` replaces
the ENTIRE object (dropping review rules and the force-push/deletion bans
unless they are re-sent), and the narrower
`PATCH .../protection/required_status_checks` sub-resource 404s when no such
object exists yet. It refuses to require a context name that has never been
reported on the branch, since that would block every PR with no error anywhere.

Verified by replaying the gate over the last 60 Backend CI runs: it blocks all
8 PR runs with a red linter and both of the merge-commit runs from #2262's
window, and allows all 25 genuinely green runs and the 3 with no backend
changes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
JSv4 added a commit that referenced this pull request Aug 20, 2026
…ired

`main`'s branch protection has no `required_status_checks` object at all, so
nothing gates a merge on CI having run, let alone passed. PR #2262 merged with
Backend CI never having run on its head commit at all -- and because nothing
was required, "no check reported" was not a blocker. The push that merged it
then failed at the linter, which skipped `pytest` (0s); `main` sat that way for
~30 hours, repaired only by accident when an unrelated PR's
`pre-commit run --all-files` happened to reformat the same file.

Requiring *something* is therefore the fix, but requiring the `pytest` job is
not, because it leaves a second hole open and opens a third:

  * GitHub reports a job skipped by its own `if:` as SUCCESS to branch
    protection. `pytest` is gated on `needs.linter.result == 'success'`, so a
    red linter skips it and a required `pytest` still reads green. This is not
    hypothetical: PRs #2260, #2264 and #2265 are all sitting at
    `linter=failure / pytest=skipped` right now, and would be mergeable under
    that policy with a red linter.
  * A workflow skipped by path filtering never reports its checks at all, so
    the required check hangs Pending forever. With `paths-ignore: docs/**` on
    the `pull_request` trigger, requiring any job here would make docs-only
    PRs permanently unmergeable.

So the requirable check has to always run and inspect the other jobs itself,
telling "skipped because this PR touches no backend code" apart from "skipped
because something upstream broke". That is the new `gate` job; its decision
table is `.github/scripts/backend_ci_gate.sh`, which carries a `--self-test`
that the job runs on every invocation -- a gate whose own logic has silently
inverted is worse than no gate.

`paths-ignore` is dropped from the `pull_request` trigger for the reason
above; the `changes` path filter still keeps the expensive jobs from running,
so a docs-only PR now costs two ubuntu-latest jobs of a few seconds.

`require_backend_ci_gate.sh` applies the protection change itself, because the
obvious `gh api` call is a footgun: `PUT .../branches/main/protection` replaces
the ENTIRE object (dropping review rules and the force-push/deletion bans
unless they are re-sent), and the narrower
`PATCH .../protection/required_status_checks` sub-resource 404s when no such
object exists yet. It refuses to require a context name that has never been
reported on the branch, since that would block every PR with no error anywhere.

Verified by replaying the gate over the last 60 Backend CI runs: it blocks all
8 PR runs with a red linter and both of the merge-commit runs from #2262's
window, and allows all 25 genuinely green runs and the 3 with no backend
changes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file python Pull requests that update Python code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants