`builtins.sum`: Spurious error for operands having `__add__` defined using `partialmethod`

[kaushikcfd]

Here's a minimal reproducer:

from __future__ import annotations
from functools import partialmethod

class A:
    def my_add(self, other: A, reverse: bool) -> A:
        return self

    __add__ = partialmethod(my_add, reverse=False)

a = A()
aa = A()
aaa = A()
result = sum([aa, a], start=aaa)

And the commands to reproduce it:

$ mypy --version
mypy 0.950 (compiled: yes)

$ mypy --show-error-codes --strict  mypy_bug_report.py 
mypy_bug_report.py:15: error: No overload variant of "sum" matches argument types "List[A]", "A"  [call-overload]
mypy_bug_report.py:15: note: Possible overload variants:
mypy_bug_report.py:15: note:     def [_SumT <: _SupportsSum] sum(Iterable[_SumT]) -> Union[_SumT, Literal[0]]
mypy_bug_report.py:15: note:     def [_SumT <: _SupportsSum, _SumS <: _SupportsSum] sum(Iterable[_SumT], start: _SumS) -> Union[_SumT, _SumS]
Found 1 error in 1 file (checked 1 source file)

Related #7735, #7578

[inducer]

It appears that this is a regression. mypy 0.942 does not object to the code in the OP.

[AlexWaygood]

This still (unsurprisingly) reproduces after the recent changes to the sum stub. Here's the current error message:

(.venv) C:\Users\alexw\coding\typeshed>mypy test.py --strict --show-error-codes --custom-typeshed-dir .
test.py:13: error: No overload variant of "sum" matches argument types "List[A]", "A"  [call-overload]
test.py:13: note: Possible overload variants:
test.py:13: note:     def sum(__iterable, Iterable[bool], start: int = ...) -> int
test.py:13: note:     def [_SupportsSumNoDefaultT <: _SupportsSumWithNoDefaultGiven] sum(__iterable, Iterable[_SupportsSumNoDefaultT]) -> Union[_SupportsSumNoDefaultT, Literal[0]]
test.py:13: note:     def [_AddableT1 <: SupportsAdd[Any, Any], _AddableT2 <: SupportsAdd[Any, Any]] sum(__iterable, Iterable[_AddableT1], start: _AddableT2) -> Union[_AddableT1, _AddableT2]
Found 1 error in 1 file (checked 1 source file)

The reason why there's now an error where previously there was none is almost certainly due to changes made in typeshed between 0.942 and 0.950 that made the stub forsum` more complicated. Nonetheless, I feel like this is sort-of a bug in mypy's understanding of higher-order callables rather than a bug in the stub. In an ideal world, mypy should be able to understand that the arguments being passed in here match the third overload here:

typeshed/stdlib/builtins.pyi

Lines 1664 to 1665 in 1828ba2

	@overload
	def sum(__iterable: Iterable[_AddableT1], start: _AddableT2) -> _AddableT1 | _AddableT2: ...

[srittau]

I agree with @AlexWaygood. The output hasn't changed much with mypy 1.11.2. A reveal_type on A.__add__ reveals def (*Any, **Any) -> foo.A. This should match sum's third overload, but doesn't for some reason. This looks like a problem with mypy to me.