Disable commonly ignored Pyright linting rules#7497
Conversation
|
The original idea behind this was we have a known set of these that already exist in the code, but we generally don't want to introduce new instances. Leaving them on by default lets us catch new issues being introduced that I don't think we otherwise have a validation mechanism. I'm +0 on this and #7496. If we want to clean up the code we can (I agree they're noisy), we're just making the type checking subtly less correct. |
Well, that's the thing with these rules; they are unrelated to type-safety; they just enforce particular conventions that doesn't really seem to be a good match for the code That said, I agree that lints can still be useful, even if they're ignored most of the time. So it's mostly a matter of taste I guess 🤷. Either way, if it helps, I wouldn't mind limiting this to disabling one (instead of four) rules. Closing this is also fine as far as I'm concerned; there's still value in thinking about things like these once in a while. |
There was a problem hiding this comment.
I gave it some more thought over the weekend and I think I'm aligned with that view. I do think reportUnnecessaryIsInstance is truly a type related check but it's not providing a lot of value right now. The rest I agree are probably wrong to be handled by pyright.
Thanks for the discussion, @jorenham!
I noticed that some Pyright error codes were often ignored, and that most of those were opinionated lints that aren't related to type-checking.
By globally disabled these rules, we reduce a lot of the
# type: ignorenoise, without hurting type-safety.FWIW; I also tend to disable most of these rules, even in projects with a maximally strict typing configuration, such as scipy-stubs (pyright config).