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

Allows to use type[T] in stubs #11863

Merged
merged 5 commits into from
Jan 6, 2022
Merged

Allows to use type[T] in stubs #11863

merged 5 commits into from
Jan 6, 2022

Conversation

sobolevn
Copy link
Member

@AlexWaygood
Copy link
Member

I don't know my way around the mypy code base very well, but it looks like this solves using type[T] in annotations, but not in other uses such as type aliases and subclasses — is that correct? 🙂 (Totally understand if you want to leave those use cases to another PR!)

@sobolevn
Copy link
Member Author

Yes, other cases are not covered yet 🙂
Only the one case I've tested.

Example:
Снимок экрана 2021-12-29 в 17 00 09

(I prefer to make a lot of small PRs instead of one big one, because they are a lot harder to get merged)

@AlexWaygood
Copy link
Member

(I prefer to make a lot of small PRs instead of one big one, because they are a lot harder to get merged)

Of course! Just wanted to clarify 🙂

Copy link
Collaborator

@hauntsaninja hauntsaninja left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, this is great.

I think the names here could use some cleaning up, if you're willing to do a little more refactoring.
self.allow_new_syntax is misleading, since it seems to be exactly the same as is_stub_file.
It would be great if we could set self.always_allow_new_syntax = self.is_stub_file or self.api.is_future_flag_set('annotations').
We could then get rid of the new method and have checks like if self.always_allow_new_syntax or self.options.python_version >= (3, 9), which seems the most readable to me.

@sobolevn
Copy link
Member Author

Sounds like a good idea! I was confused with allow_new_syntax as well. Will do tomorrow.

@sobolevn
Copy link
Member Author

sobolevn commented Dec 30, 2021

@hauntsaninja done!

I've also added a TODO for myself for later. We need to double check that it handles __future__ import correctly. Ok, it only check rhs, which is not affected by __future__.

@hauntsaninja hauntsaninja merged commit 37886c7 into python:master Jan 6, 2022
@hauntsaninja
Copy link
Collaborator

Hooray!

JukkaL pushed a commit that referenced this pull request Jan 6, 2022
tushar-deepsource pushed a commit to DeepSourceCorp/mypy that referenced this pull request Jan 20, 2022
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.

3 participants