Adding an --ignore-missing-type-hints config #10660

Activity

1. evinism

   added

   feature

   on Jun 16, 2021
2. evinism commented on Jun 16, 2021

   

   evinism

   on Jun 16, 2021

   Last edited by evinism

   Author

   More actions

   For reference, here's the incomplete idea of what i'm going for in my fork: evinism#1

   If it turns out there's no reason this hasn't been implemented, I'll brush it up and submit a PR.
3. JukkaL commented on Jun 17, 2021

   

   JukkaL

   on Jun 17, 2021

   Collaborator

   More actions

   My first impression is that the overall idea sounds reasonable. We may want to bikeshed some of the details though.

   I haven't thought about this carefully yet, but here are some random thoughts:

   • We could plausibly introduce a special error code for these errors. It would then be possible to ignore the error code. However, this would be a backward incompatible change, unless we also add support for a hierarchy of error codes. If we'd do that, the new error could be a sub-error of the original error code, and ignoring the original error code would also ignore the sub-error.
   • This would apply to at least installed packages without type hints. We could also make this work with known third-party packages for which we ask the user to install a types-* package. However, the latter case is more actionable, so perhaps it shouldn't be covered.
4. hauntsaninja commented on Jun 17, 2021

   

   hauntsaninja

   on Jun 17, 2021

   Collaborator

   More actions

   Related: #9789
5. evinism commented on Jun 18, 2021

   

   evinism

   on Jun 18, 2021

   Last edited by evinism

   Author

   More actions

   @JukkaL Good to know! Forgive me if these questions don't make any sense, i'm very new to this project.

   First bullet

   For (1), to make it more concrete, I take it that what you're proposing is either:

   • 1a. splitting the import error code into two, for example import and has-stubs backwards incompatibly, or
   • 1b. creating a new abstraction on top of error codes to support sub-errors, e.g. import which has import:has-stubs and import:no-missing-module as suberrors

   Is this interpretation correct?

   To nail it down further, as i understand, the user benefit of adding in an error code representation is that we can add inline annotations to ignore it, e.g. # type: ignore[import:has-stubs] in the code. Is that interpretation also correct?

   I wonder if there's other uses for sub-errors that haven't been explored yet, or what other static analyzers do, etc. Has such a thing been brought up before?

   Second Bullet

   For (2), just from a 'least surprising behavior' perspective, i'd imagine that --ignore-missing-type-hints would also ignore missing type hints for which there is an easy way to get those type hints. I'd imagine that'd be a good thing to get right first time.
6. hauntsaninja commented on Feb 20, 2023

   

   hauntsaninja

   on Feb 20, 2023

   Collaborator

   More actions

   Thanks for the feature request. I'm going to close this as a duplicate of #9789. I opened a PR with a proposed implementation here: #14740
7. hauntsaninja

   closed this as not plannedon Feb 20, 2023