Closed jakkdl closed 1 year ago
We already disabled TC100 for stubs files here.
Which error types do you think would be useful for stubs files, and which errors aren't?
TC001, TC002 and TC003 are all about moving imports into a type-checking block - and can therefore be disabled. TC004 makes me think that maybe it should request that all imports should be moved out of type-checking blocks, plausibly as a new error code. TC200 should be disabled for the same reason as TC100. You could maybe even raise TC201 for all stringified parameters. And TC006 should never be raised in stub files either.
... which means that the only remaining useful ones would be TC101/TC201, and TC004/[new error code for existence of type-checking blocks].
Sounds to me like skipping .pyi
would be the most pragmatic solution. Adding dynamic behavior for stubs files doesn't seem to be of much value to anyone. Does that seem reasonable to you?
Yepyep
Interested in creating the PR? :slightly_smiling_face:
Requesting that imports be moved into a type-checking block does not make sense when linting stub files, since they will only be executed in a typing context. There may be other error codes that also should be disabled in stub files.
flake8
s--filename
parameter includes.pyi
files by default, so this happens even if an end-user doesn't explicitly try to type-check their stub files.