python / python/mypy

Feature Request: a secondary error for overrides based on compatibility

Open
#17,243 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

feature
Dominant language
Python
Stars
20.6k
Forks
3.3k
PR merge metrics
PR metrics pending

Description

Feature

Apologies if I this has been discussed before. I did search the archives for past issues.

I am porting a legacy project to mypy and have run into several issues with LSP that generate a [override] error as outlined on https://mypy.readthedocs.io/en/stable/common_issues.html#incompatible-overrides

As I've been working on this effort, I've noticed two main situations that generate this issue. I'll use the examples on the docs to illustrate

Given:

from typing import Sequence, List, Iterable

class A:
    def test(self, t: Sequence[int]) -> Sequence[str]:
        ...

1- Most problems are due to a narrowing of the argument, as the docs show

class NarrowerArgument(A):
    def test(self, t: List[int]) -> Sequence[str]:  # type: ignore[override]
        ...

2- However, some problems are due to a developer completely breaking the API, such as changing the input variables and types completely:

class WildlyDifferent(A):
    def test(self, tt: List[str], foo:int) -> Sequence[str]:  # type: ignore[override]
        ...

Both of these situations generate the same error codes, meaning an ignore for one will ignore the other.

Pitch

I think it would be incredibly useful to people porting legacy code if overrides could be broken down into (at-least) these two types, so they can be triaged and scheduled into sprints accordingly.

When dealing with large legacy projects, these errors are plentiful. While the narrowing of input values for Type Safety needs to be addressed, that need is often secondary to addressing the invocation of a function that uses a wildly different call signature - and has likely missed unit tests and code coverage for several years of API/Library updates.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the override compatibility checks that emit the [override] error, using the incompatible-overrides section of the mypy documentation and the examples in this issue. Define how narrowing arguments should be distinguished from a substantially different call signature, then add coverage showing that each case receives its intended diagnostic.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
devtools
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.