-
-
Notifications
You must be signed in to change notification settings - Fork 1.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
Stubtesting types which aren't exposed anywhere #13016
Labels
project: infrastructure
typeshed build, test, documentation, or distribution related
Comments
AlexWaygood
added
the
project: infrastructure
typeshed build, test, documentation, or distribution related
label
Nov 14, 2024
stubtest results found this way:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I saw #13013 and it reminded me of an idea I have been weighing. Right now stubtest can't run against a type like
os._ScanDirIterator
because it's not importable. What do people think about providing additional configuration that would help stubtest get access to the runtime class object?I put together a quick working implementation which goes like this:
Typeshed get a file named
stdlib/@tests/stubtest_extra_imports.py
. In that file is a dictionary namedIMPORT_MAPPING
. To get access toos._ScanDirIterator
, it looks like this:tests/stubtest_stdlib.py
adds an extra flag of--imports-file stdlib/@tests/stubtest_imports.py
to the stubtest invocation, and stubtest imports this file. When stubtest gets a runtime entry ofMISSING
, it checks if the entry it's looking for is in the IMPORT_MAPPING table, in which case it executes the function to get the runtime, and then continues testing.The naming of everything can be tweaked, and this exact arrangement might have trouble scaling. But it works and allows stubtest to produce:
Thoughts? Is this worth pursuing?
The text was updated successfully, but these errors were encountered: