-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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: verify the contents of __all__
in a stub
#12214
Conversation
This comment has been minimized.
This comment has been minimized.
0757335
to
2b41db4
Compare
This comment has been minimized.
This comment has been minimized.
(I'll mark this as draft until I've whittled down the typeshed hits to a more acceptable number.) Following commit 859df5a, which reduces the number of duplicate errors if a stub is missing |
This comment has been minimized.
This comment has been minimized.
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
After many typeshed PRs, merging this PR would now produce only the following 8 hits when run on my Windows machine (Python 3.10): + asyncio.__all__ is not present in stub
+ asyncio.windows_utils module: names exported from the stub do not correspond to the names exported at runtime.
+ Note: This is probably either due to an inaccurate `__all__` in the stub, or due to a name being declared in `__all__` but not actually defined in the stub.
+ distutils.command.__all__ is not present in stub
+ email.__all__ is not present in stub
+ locale module: names exported from the stub do not correspond to the names exported at runtime.
+ Note: This is probably either due to an inaccurate `__all__` in the stub, or due to a name being declared in `__all__` but not actually defined in the stub.
+ os.__all__ is not present in stub
+ socket.__all__ is not present in stub
+ xml.__all__ is not present in stub Here's the more verbose versions of these errors
Notes on the remaining hits:
|
@hauntsaninja, could you possibly try running this patch on Linux, to see if there are any unix-only modules that I've missed? :) |
Note that this PR shouldn't have a significant effect on checking third-party stubs in typeshed:
|
On my linux system, comparing the output of +_pydecimal.__all__ is not present in stub
+asyncio.__all__ is not present in stub
+asyncio.base_events module: names exported from the stub do not correspond to the names exported at runtime.
+(Note: This is probably either due to an inaccurate `__all__` in the stub, or due to a name being declared in `__all__` but not actually defined in the stub.)
+distutils.command.__all__ is not present in stub
+email.__all__ is not present in stub
+os.__all__ is not present in stub
+poplib module: names exported from the stub do not correspond to the names exported at runtime.
+(Note: This is probably either due to an inaccurate `__all__` in the stub, or due to a name being declared in `__all__` but not actually defined in the stub.)
+socket.__all__ is not present in stub
+tty.__all__ is not present in stub
+typing module: names exported from the stub do not correspond to the names exported at runtime.
+(Note: This is probably either due to an inaccurate `__all__` in the stub, or due to a name being declared in `__all__` but not actually defined in the stub.)
+typing_extensions.__all__ is not present in stub
+xml.__all__ is not present in stub |
Thanks! I'm travelling for the next few days, but I'll try to look at fixing some of these when I have the time. |
@Akuli, could you possibly tell me which Python version you're running on, and give me the full results for |
Python 3.9.2 The typing error is:
There's several errors coming from All asyncio.base_events errors
|
The The So I believe all the linux-only hits should be fixed by python/typeshed#7618. Thanks very much for your help! |
It doesn't exist at runtime: ```python >>> import dateparser.date >>> dateparser.date.Self Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: module 'dateparser.date' has no attribute 'Self' ``` ...and it's not used in the stub either. I'm not sure why stubtest didn't pick it up. My stubtest patch over at python/mypy#12214 _does_ pick it up (and I'm not sure why that is, either... but it's a true positive!)
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.
Thanks, this is a great change!
__all__
in a stub__all__
in a stub
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.
Thank you again, this is super useful functionality
Filed #13300 for checking the presence :-) |
Thank you for the review and merge!! Excited to see this go in 😀 |
Description
Fixes python/typeshed#7284.
Stubtest currently does not check for the presence of
__all__
in a stub. Moreover, even if__all__
is defined in the stub, stubtest does not currently check that the stub's__all__
matches the runtime's__all__
. This PR fixes that!Test Plan
I've modified an existing test case and added a new one.
New errors reported by stubtest when checking typeshed, with this patch applied.
There are... 344 new errors reported by stubtest, with this PR applied, so it may not yet be mergeable. I've attached the full list of errors as a
.txt
file.all_discrepancies.txt