Split import-untyped into two different error codes depending on whether stubs are available to install
#18661
Comments
|
This makes sense to me! Assuming that the list of things mypy detects as being available only changes when, say, mypy is updated, so that random contributors to your project aren't getting jumpscared by unrelated type errors. I don't know anything about how mypy does this, but it's probably something like this? Assuming that's the case, I think the latter suggestion, making them import-untyped-stubs-available, is the best one. This lets all current import-untyped ignore codes work except where maintainers can improve their types by installing the available stubs. (And if they don't want that for some reason, the new code can be globally ignored.) Although perhaps I am a bit too optimistic about the average enthusiasm for improving one's types. There is a concept of subcodes in the error codes, but making the new code a subcode of the old code defeats the above advantage. Also, the old code is already a subcode of import, and the system doesn't support subsubcode at the moment. There's also the possibility of emitting 2 codes, but I'm not convinced that would ultimately be any more helpful. Adding this code would be, based on a brief search I just did through the codebase, very easy. I coincidentally have familiarized myself with the errorcode system recently, so I'm in a good position to make a PR about this, I think. |
Feature
Implement separate error codes for (1) untyped imports without stubs available and (2) untyped imports with stubs available.
Pitch
As explained under Missing imports in the docs, there are two different categories of untyped imports. Currently, both of these categories are grouped under the
import-untypederror code. For example:No stubs available (documented here):
Stubs available (documented here):
I propose that these categories should fall under different error codes, either by changing the error code for both of these categories (and removing the
import-untypederror code) or by changing the error code for only one of the categories, and leaving the other asimport-untyped. For example, the second category could fall under a newimport-untyped-stubs-availablecode.This would allow configuring mypy to handle these two categories differently. For example, I would like to always ignore errors for untyped third-party libraries without stubs available, but always show errors for libraries with stubs available, so that I know which stub packages I should add to my project dependencies. The available solutions for achieving this all have drawbacks:
disable_error_code = import-untypedignores both of the above categories, so you won't be notified about libraries with available stubs.--install-typesoption as part of CICD workflows is brittle and not recommended (see Option "install-types" breaks project version dependencies. #17852), so doesn't scale well when maintaining many different repositories where running--install-typeslocally for every project on a regular basis is not feasible.import-untypederror code for individual imports is again inconvenient when managing many different projects with many third-party dependencies. Also, if you ignore theimport-untypederror code for a particular import and then the library later adds type stubs, mypy won't notify you that there is a stub package available to install.The text was updated successfully, but these errors were encountered: