Repository navigation
mypy 2.0 big change list #17967
Description
This is a reminder list for changes we may want to do in a major version (that we know are relatively easy to flip on).
- Announce (beta of) parallel type checking
- Local partial types Allow inverting --local-partial-types #18377 Enable local partial types by default #10169
- Remove logic for legacy bundled stubs Remove logic for legacy bundled stubs #18372
- SQLite cache on by default
- Fixed format cache on by default
- Delete the Python 2 extra from setup.py Delete Python 2 extra #18374
- Prevent assignment to None for class variables Prevent assignment to None for non-Optional class variables #20054
- Rename
--allow-redefinition-newtoallow-redefinition(and keep--allow-redefinition-old) - PEP 688 change bytearray memoryview promotion by default Enable strict_bytes by default #18371
Needs more discussion:
- Get rid of
--no-namespace-packages - Interpret type as type[Any]?
- Move func-returns-value to disabled by default error code?
For general not-so-easy changes we want to do, see #16472 (major/minor isn't the most meaningful for a lot of the most important changes we want to do, e.g. --new-type-inference was in 1.7)
See also https://github.com/python/mypy/wiki/Release-Process#policy-for-backward-incompatible-changes
(feel free to edit)
Activity
brianschubert commentedon Oct 31, 2024
JukkaL commentedon Nov 5, 2024
I'd also like to add narrowing on initial assignment (#2008). We'd need to first add a feature flag to opt-in to the new behavior before 2.0.
emmatyping commentedon Dec 27, 2024
I believe the behavior change in #6577 would likely be breaking, so mypy 2.0 would be a good time to do it.
emmatyping commentedon Dec 27, 2024
I also think making
--check-untyped-defsthe default is a pretty significant change that we'd probably want to communicate and make in mypy 2.0 ref #6646cdce8p commentedon Jan 27, 2025
I think it would make sense to remove support for
mypy_extensions.TypedDictandmypy_extensions.NoReturnwith2.0as well. They are deprecated upstream and will raise DeprecationWarnings with the next mypy_extensions release.Might also make sense to add dedicated warnings for them in mypy itself as well.
#18550 adds an upper bound, so we don't break old code once they are removed.
JukkaL commentedon Jan 28, 2025
Keeping support for them around seems pretty low maintenance. We could instead generate an error with a specific error code when we encounter these in 2.0 (and optionally in a pre-2.0 version), but we'd still preserve other functionality. Disabling the error code would keep the existing behavior.
JukkaL commentedon Jan 28, 2025
Yes, now is the right time to make a decision, and we'd need to announce before 2.0. I'm tentatively leaning towards doing it in 2.0, but having #18516 or other similar functionality first would be nice to reduce the number of false positives.
davidhalter commentedon Jan 31, 2025
I personally think that it would be nice to come to a decision around union vs. join (#12056 (comment)). I'm unsure whether Mypy currently passing some conformance tests because of this or not. It will probably just affect a lot of code bases.
JukkaL commentedon Feb 4, 2025
We are gradually moving towards using unions instead of joins, but it's not clear yet whether we will replace joins everywhere. We'll need to experiment and see the impact before making any decisions. It's possible that some breaking changes need to wait until 2.0 or 3.0 -- we can break backward compatibility, but we need to be careful with it. Creating a draft PR and seeing the impact on mypy_primer is a good way to move this forward.
hamdanal commentedon Feb 2, 2026
Could mypy 2.0 allow redefinitions by default? It is what most users expect anyway and without it beginners suffer sometimes as we saw in the numpy issue that prompted the addition of the new flag.
hauntsaninja commentedon Feb 3, 2026
We should make it the default, but I think that will need to be a mypy 3.0 change. It needs more bake time.
There's 3000 lines of primer if anyone here is interested trying to figure out some of the issues hauntsaninja#8 (comment) / improving results when used on mypy itself #20515
brianschubert commentedon Mar 22, 2026
2.0 could be a good time to doing something with
--install-types. See e.g. #18156, #10600hauntsaninja commentedon Apr 25, 2026
Given the release of mypy 2 is imminent, I'm closing this. Yay!
The easily flippable suggestions are mostly done, any discussion of other should be in #20726
The suggestions that will take work are probably now out of scope (unless someone produces a PR very quickly) and so best tracked at #16472 or similar