Diff from mypy_primer, showing the effect of this PR on type check results on a corpus of open source code:

xarray (https://github.com/pydata/xarray)
+ xarray/namedarray/dtypes.py: note: In function "maybe_promote":
+ xarray/namedarray/dtypes.py:86: error: Too many arguments for "generic"  [call-arg]

Diff from mypy_primer, showing the effect of this PR on type check results on a corpus of open source code:

xarray (https://github.com/pydata/xarray)
+ xarray/namedarray/dtypes.py: note: In function "maybe_promote":
+ xarray/namedarray/dtypes.py:86: error: Too many arguments for "generic"  [call-arg]

Relevant code: https://github.com/pydata/xarray/blob/98732e76481bdf5c497a030657cff32db134e27d/xarray/namedarray/dtypes.py#L48-L86

This new primer error is a true positive. They're calling dtype_out.type(fill_value) with dtype_out: np.dtype[np.generic]. Type-checkers will interpret that as np.generic(fill_value).
It's easy to fix by using np.dtype instead of np.dtype[np.generic] in the function signature. A generic-typing approach could also work, but would be more involved.

Thanks Joren. IIUC, it is up to xarray to fix the problem.

IIUC, it is up to xarray to fix the problem.

That's right