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

mypy 2.0 big change list #17967

Open
hauntsaninja opened this issue Oct 16, 2024 · 9 comments
Open

mypy 2.0 big change list #17967

hauntsaninja opened this issue Oct 16, 2024 · 9 comments
Labels
meta Issues tracking a broad area of work

Comments

@hauntsaninja
Copy link
Collaborator

hauntsaninja commented Oct 16, 2024

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

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)

@hauntsaninja hauntsaninja added the meta Issues tracking a broad area of work label Oct 16, 2024
@brianschubert
Copy link
Collaborator

@JukkaL
Copy link
Collaborator

JukkaL commented 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
Copy link
Collaborator

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

@emmatyping
Copy link
Collaborator

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
Copy link
Collaborator

cdce8p commented Jan 27, 2025

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
Copy link
Collaborator

JukkaL commented Jan 28, 2025

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
Copy link
Collaborator

JukkaL commented Jan 28, 2025

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
Copy link

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
Copy link
Collaborator

JukkaL commented Feb 4, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta Issues tracking a broad area of work
Projects
None yet
Development

No branches or pull requests

6 participants