Skip to content

Pin mypy_extensions to <2 #18550

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

Closed
wants to merge 1 commit into from
Closed

Conversation

cdce8p
Copy link
Collaborator

@cdce8p cdce8p commented Jan 27, 2025

mypy_extensions.TypedDict and mypy_extensions.NoReturn were recently deprecated and will be removed eventually. Add an upper bound now so we don't break old code using these types in the future, after they are removed from mypy_extensions.

@hauntsaninja
Copy link
Collaborator

Hmm could you spell out the situation in which this bound is useful?

Copy link
Contributor

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

@cdce8p
Copy link
Collaborator Author

cdce8p commented Jan 27, 2025

Hmm could you spell out the situation in which this bound is useful?

Hmm, it depends. The user has to pin an old mypy version without pinning mypy_extensions while using the old mypy_extensions.TypedDict. If the environment is setup from scratch, version 2.0 would be installed causing a RuntimeError. Notably, mypy would still be fine, as we only use the stub for type checking which is shipped with mypy itself.

Tbh I'm not sure myself how common that is. For typing_extensions I've seen lots of pins, not so much for mypy_extensions. Then again the fix for the user would be trivial.

Ideally everybody has stopped the old TypedDict / NoReturn by then anyway.

What do you think? In the end it's just an edge case anyway, so I'd be also be fine if we don't do it.

@hauntsaninja
Copy link
Collaborator

Hm, that sounds niche, and I'm not even sure the mypy version even matters here (if the user is pinning the mypy version, they're not going to pick up this PR). I think we should just roll forward, if we want to avoid breaking things here then we should just not make the breaking change in mypy_extensions in the first place.

Going to close, but lmk if I got it wrong!

@cdce8p
Copy link
Collaborator Author

cdce8p commented Jan 29, 2025

Hm, that sounds niche

Yeah, it is. I debated it myself if I should even open it. Was slightly in favor, so I did.

I'm not even sure the mypy version even matters here (if the user is pinning the mypy version, they're not going to pick up this PR).

Yes, this would have only applied to mypy versions released between now and 2.0 making it even more niche.

I think we should just roll forward, if we want to avoid breaking things here then we should just not make the breaking change in mypy_extensions in the first place.

I'd personally be completely fine with removing it after a deprecation period. The sense I've got so far though is that breaking changes in mypy are heavily discouraged. It would just be awesome if we could get rid of mypy_extensions.TypedDict at some point.

Going to close, but lmk if I got it wrong!

👍🏻 Works for me.

@cdce8p cdce8p deleted the pin-mypy_extensions branch January 29, 2025 01:11
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.

None yet

2 participants