-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Conversation
for more information, see https://pre-commit.ci
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
test-data/unit/check-classes.test
Outdated
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, thanks!
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
This comment has been minimized.
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)
|
There are several
TODO
items for the future (not this PR):@type_check_only
@overload
ed functions. But, how? There are two options: we can treat individual overload cases as@type_check_only
or we can treat the whole func. Sincetypeshed
does not have any examples of this, I prefer to defer this discussion to somewhere else and support this when we decideRefs #15146