Reconsider `--extra-checks`

[hauntsaninja]

--extra-checks was added per this review comment: https://github.com/python/mypy/pull/15425#issuecomment-1604275753

I think a big advantage of mypy relative to other type checkers is that it is relatively configurable. mypy's always had a number of config flags and the error code system that we've been encouraging allows users to enable and disable errors with granularity.

--extra-checks is not self-descriptive, it's not immediately obvious what it turns on or off. If I was a user and ran into a false positive/negative, I would not be able to connect it with the option. It's also part of --strict, so it's not even that extra — most users serious enough about type checking to know what the flag does will already have it on. I vote we keep --strict-concatenate and add --strict-typeddict-update. We can keep both of these as part of --strict and keep --extra-checks for backwards compatibility.

If we want to do more bundling of flags / error codes, I feel we should generalise --strict.

[sobolevn]

I agree, let's do that for [email protected]

[SastaDev]

+1, Just had this issue with my decorator implementation and took me days to know it's because of --extra-checks enabled by --strict and the error message is not even helpful to understand:

Code:

from collections.abc import Callable
from functools import wraps

class Client:
    ...
class NewClient:
    ...

new_client = NewClient()

def decorator(
    func: Callable[Concatenate[NewClient, P], R]
) -> Callable[Concatenate[Client, P], R]:
    @wraps(func)
    def wrapper(
        client: Client,
        *args: P.args,
        **kwargs: P.kwargs
    ) -> R:
        return func(new_client, *args, **kwargs)

    return wrapper

Error:

error: Incompatible return value type (got "_Wrapped[[NewClient, **P], R, [Client, **P], R]", expected "Callable[[Client, **P], R]")  [return-value]
note: "_Wrapped[[NewClient, **P], R, [Client, **P], R].__call__" has type "Callable[[Arg(Client, 'client'), **P], R]"

[wyattscarpenter]

There's no need to wait for mypy 2.0 to do this, since it will all be backwards compatible.

I wonder if these two checks could be refactored to produce specific error codes. In some sense that would be ideal, since we could promote --enable-error-code for them and regard the other flags as aliases for that.