Cast for input function monkey-patch doesn't fix things as expected type changes

Bug Report

I'm writing code that monkey-patches the built-in input function, like so:

import builtins

def f(x: str) -> str:
    print(x)
    return 'hi'

builtins.input = f

print(input('what'))  # prints 'what' and then 'hi'

MyPy reasonably gives me a type error on the assignment to input, saying:

t.py:7: error: Incompatible types in assignment (expression has type "Callable[[str], str]", variable has type "Callable[[object], str]")  [assignment]
Found 1 error in 1 file (checked 1 source file)

Okay, fine so I change my code like this, exactly matching the reported variable type:

import builtins

from typing import cast, Callable

def f(x: str) -> str:
    print(x)
    return 'hi'

builtins.input = cast(Callable[[object], str], f)

print(input('what'))  # prints 'what' and then 'hi'

I'm now casting to exactly what the error message said was expected. However, I still get a mypy error on the same line, and the expected type has changed:

t.py:9: error: Incompatible types in assignment (expression has type "Callable[[object], str]", variable has type "Callable[[DefaultArg(object)], str]")  [assignment]
Found 1 error in 1 file (checked 1 source file)

Looking it up, it seems like DefaultArg is from mypy_extensions? That wasn't obvious, but I can get this to work by doing:

import builtins

from typing import cast, Callable
from mypy_extensions import DefaultArg

def f(x: str) -> str:
    print(x)
    return 'hi'

builtins.input = cast(Callable[[DefaultArg(object)], str], f)

print(input('what'))  # prints 'what' and then 'hi'

To Reproduce

Run the code snippets provided above through mypy by saving them to a file and running mypy filename.

Expected Behavior

If I cast to the type that the error message says it needs, then the type error should go away.

If an "optional extensions" type is required to correctly type code dealing with a core built-in function, it should be mentioned somewhere in the python.org core documentation maybe? I first turned to searching docs.python.org to figure out what DefaultArg was so I could figure out where to import it from, but there are zero hits. Web searches without careful quoting are near useless, since modern search engines find all sorts of conversations about default arguments that have nothing to do with mypy. Thankfully I was clued in enough to search my mypy documentation pages and finally found it. I realize this may not be fixable, but maybe some kind of reminder could be included in the error message when DefaultArg is required?

The minimal correct fix here should be for the original error message to include DefaultArg in the expected type, since defining a function which has no default for its first argument and setting that as input will cause crashes for people who expect the usual behavior.

Actual Behavior

First type error message is just wrong about the expected/required type.

Your Environment

• Mypy version used: 1.8.0, so I upgraded to 1.10.1 (current latest) and have the exact same issue.
• Mypy command-line flags: None
• Mypy configuration options from mypy.ini (and other config files): none specified
• Python version used: 3.11.8

Reproduisez le problème en enregistrant les snippets fournis et en exécutant mypy sans options de ligne de commande ni configuration. Commencez par retracer la manière dont la signature intégrée de input et DefaultArg sont rendus dans l'erreur d'affectation ; c'est terminé lorsque le diagnostic initial signale la forme DefaultArg requise et ne suggère plus un cast insuffisant.