Skip to content

Allows to use type[T] in stubs - #11863

Merged
hauntsaninja merged 5 commits into
python:masterfrom
sobolevn:better-type-in-stubs
Jan 6, 2022
Merged

hauntsaninja merged 5 commits into
python:masterfrom
sobolevn:better-type-in-stubs

Conversation

@sobolevn

Copy link
Copy Markdown
Member

@AlexWaygood

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

@hauntsaninja hauntsaninja left a comment •

Copy link
Copy Markdown
Collaborator

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
Copy Markdown
Member Author

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

@sobolevn

sobolevn commented Dec 30, 2021 •

Copy link
Copy Markdown
Member Author

@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
Copy Markdown
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