Description
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-untyped error code. For example:
-
No stubs available (documented here):
error: Skipping analyzing "boto3": module is installed, but missing library stubs or py.typed marker [import-untyped] -
Stubs available (documented here):
error: Library stubs not installed for "requests" [import-untyped] note: Hint: "python3 -m pip install types-requests"
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-untyped error code) or by changing the error code for only one of the categories, and leaving the other as import-untyped. For example, the second category could fall under a new import-untyped-stubs-available code.
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:
- Using
disable_error_code = import-untypedignores both of the above categories, so you won't be notified about libraries with available stubs. - Using the
--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. - Ignoring the
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.
Metadata
Metadata
Assignees
Projects
Milestone
Relationships
Participants
Activity
install_typesoption causes silent dependency conflicts ASFHyP3/actions#257wyattscarpenter commentedon May 14, 2025
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.