mypy 2.0 big change list

[hauntsaninja]

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-new to allow-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)

[brianschubert]

• Enable --warn-unreachable in --strict in Mypy 2.0 #18078

[JukkaL]

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]

I believe the behavior change in #6577 would likely be breaking, so mypy 2.0 would be a good time to do it.

[emmatyping]

I also think making --check-untyped-defs the default is a pretty significant change that we'd probably want to communicate and make in mypy 2.0 ref #6646

[cdce8p]

I think it would make sense to remove support for mypy_extensions.TypedDict and mypy_extensions.NoReturn with 2.0 as 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]

I think it would make sense to remove support for mypy_extensions.TypedDict and mypy_extensions.NoReturn with 2.0 as well. They are deprecated upstream and will raise DeprecationWarnings with the next mypy_extensions release.

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]

I also think making --check-untyped-defs the default is a pretty significant change that we'd probably want to communicate and make in mypy 2.0

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]

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]

I personally think that it would be nice to come to a decision around union vs. join

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]

• Rename --allow-redefinition-new to allow-redefinition (and keep --allow-redefinition-old)

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.