What is the future of overload resolution?

Consider this real life code:

from typing import Any
import numpy as np

def f(x: np.ndarray[Any, np.dtype[np.floating[Any]]]):
    reveal_type(np.square(x) + np.square(x))

Pyright reveals a Boolean array whereas MyPy says that it is Any.

More cases and information can be found here and here.

This doesn’t seem to be a bug with NumPy, Pyright, or MyPy. But it is a problem for users who use the dtype annotation. Is there a way to fix this in the future? Perhaps by standardizing overload resolution?

Yes, overload resolution is under-specified in the Python type system. I agree it’s something that should be spec’ed. It’s on a long list of typing issues that I’ve been tracking.

If you are interested in this issue and would like to spearhead the effort to document the standard behavior, you’re welcome to do so.

I gave up trying to fully replicate mypy’s overload behavior in pyright. I found that mypy’s behavior didn’t even match its own documentation in some cases. I also found cases where it produced results that seemed to be internally inconsistent. Without a formal and detailed spec, it’s difficult to say whether any behavior is correct (or even intended).

2 Likes

Related topic: Some improvements to function overloads (in particular last comment by @erictraut).

As the typing spec was added recently in this PR, I believe this could be standardized here? (by contributing directly to the python/typing repo).

This will probably require a lot of work, especially regarding breaking changes that could potentially be introduced in type checkers to comply with this future spec.

Could you start by filing an issue there?