Replies: 1 comment 10 replies
-
The After asking about it, it turns out that the
Hmm I'm probably not the best person to ask about this, so perhaps @rgommers could help us out here?
Haha, that very same idea popped into my head when doing groceries just now. It's pretty strange that the community objected... I think that a
Yea good idea. Disallowing the type completeness score to go down seems safer than requiring an lower bound. The script would have to install numpy + run pyright twice. But I don't expect that to become the bottleneck of the CI, since mypy_primer also does something like that. Caching the json output using for a particular commit hash could also help. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Tagging @jorenham and @MarcoGorelli
This discussion is a follow-up to this thread.
Joren, you mentioned in that thread that it would be useful if the
--verifytypes
feature in pyright allowed for exclusions (e.g. for test code). The--verifytypes
feature is intended to run on the installed library, and most libraries don't ship test code with the package. It looks like numpy does bundle some of its tests. I see atests
and atesting
directory. I presume this is intentional and not just a packaging oversight?In a few other cases where library authors asked me about packaged test code, I recommended that they rename their test directory to
_tests
. The underscore is the standard mechanism that tells tools that the directory is considered private — not part of the public interface of the library. If it's namedtests
(no underscore), then language servers will offer completion suggestions (including auto-import completions) that target this directory. That's probably not ideal for users. If there's good reason to ship tests with numpy, what are your thoughts on renaming the directory to_tests
? Or would that be too disruptive?You mentioned in the other thread that adding support for some exclusion mechanism for
--verifytypes
would help here. Leveraging the existingexclude
probably doesn't make sense because that setting is intended to define which source files are in your project, but--verifytypes
doesn't work on project code; it operates on the code that is installed in your Python environment. I guess that I could add a separate exclusion mechanism, but that still wouldn't address the fact that language servers would still think thattests
is part of the public interface for the library. Maybe we need some other industry-standard way for a library to indicate which subdirectories or submodules are considered "public". I previously explored expanding the contents of the "py.typed" file for this purpose, but the feedback from the community was pretty negative. They didn't want to complicate "py.typed".You also mentioned that you're looking for some way to avoid back-sliding on progress toward type completeness. I wonder if you've considered some sort of diffing mechanism here. The
--verifytypes
command can be combined with--outputjson
, which allows the resulting report to be processed easily by scripts. A CI script could do a before-and-after comparison and use the diff to look for regressions. Just a thought.Beta Was this translation helpful? Give feedback.
All reactions