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

[stubtest] support @type_check_only decorator #16422

Merged
merged 5 commits into from
Nov 11, 2023
Merged

[stubtest] support @type_check_only decorator #16422

merged 5 commits into from
Nov 11, 2023

Conversation

sobolevn
Copy link
Member

@sobolevn sobolevn commented Nov 8, 2023

There are several TODO items for the future (not this PR):

  • Add an error code to disallow importing things that are decorated with @type_check_only
  • Support @overloaded functions. But, how? There are two options: we can treat individual overload cases as @type_check_only or we can treat the whole func. Since typeshed does not have any examples of this, I prefer to defer this discussion to somewhere else and support this when we decide

Refs #15146

Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
Copy link
Member

Choose a reason for hiding this comment

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

Not sure I fully understand what the point is of adding the tests you've added in this file, since they all seem to be asserting undesirable behaviour

Copy link
Member Author

Choose a reason for hiding this comment

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

It is not undersirable, it just a status-quo. It is expected to be working like this for now. We don't have any other expected behavior for now.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, and the status quo is undesirable -- ideally, mypy would fully support @type_check_only. If somebody came along and implemented the feature in the future, I think it would be highly confusing if existing tests started failing as a result of the feature being implemented

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok, we now know that these tests work and can add them later.
I am actually interested in working on this further :)

This comment has been minimized.

Copy link
Member

@AlexWaygood AlexWaygood left a comment

Choose a reason for hiding this comment

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

Looks great, thanks!

Copy link
Member

Choose a reason for hiding this comment

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

Do we need the changes to the fixtures anymore, after the latest push?

Copy link
Member Author

Choose a reason for hiding this comment

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

It is typing-full, it won't hurt.

Copy link
Member

Choose a reason for hiding this comment

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

Sure, makes sense

This comment has been minimized.

Copy link
Contributor

Diff from mypy_primer, showing the effect of this PR on open source code:

discord.py (https://github.com/Rapptz/discord.py): typechecking got 1.07x slower (148.4s -> 159.0s)
(Performance measurements are based on a single noisy sample)

@sobolevn sobolevn merged commit e4c43cb into master Nov 11, 2023
18 checks passed
@sobolevn sobolevn deleted the issue-15146 branch November 11, 2023 21:00
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