1.1.395: @overload decorator seems ignored

[lt-brs]

Describe the bug
Newly released version 1.1.395 don't distinguish typing that depends on argument values, using typing overload decorator.
(I apologize if the behavior is the one expected)

Code or Screenshots

Example using pd.read function that output a pd.DataFrame by default and a TextFileReader if argument chunksize is not None .

import pandas as pd

y = pd.read_csv("test.csv")
len(y)

y can only be a DataFrame

pyright output:

backend/pyright_bug_reproduction.py:4:5 - error: Argument of type "DataFrame | TextFileReader" cannot be assigned to parameter "obj" of type "Sized" in function "len"
    Type "DataFrame | TextFileReader" is not assignable to type "Sized"
      "TextFileReader" is incompatible with protocol "Sized"
        "__len__" is not present (reportArgumentType)

pandas version is 2.2.3.

VS Code preview screenshots of types:

[erictraut]

Thanks for the bug report.

The behavior change is due to this bug fix.

The change affects how pyright handles this code sample.

def foo(x: str | None = ...):
    pass

The typing spec indicates that ... is a valid default argument expression when used in a stub file. It doesn't say anything about how ... should be interpreted in a non-stub (".py") file. Should it be interpreted as an EllipsisType instance? It's not clear.

The pandas library uses ... as a default argument value in some of its overload definitions. The recent change causes those overloads to never be matched.

I think it makes sense to reverse this behavior change. It probably also makes sense to try to get a clarification added to the typing spec so library maintainers and type checking maintainers are on the same page.

[erictraut]

I've started this discussion in the Python typing forum that relates to this issue. You're welcome to join that discussion if you have an opinion on the topic.

[erictraut]

I've published a hotfix release of pyright (1.1.396) to address this issue. I reverted the previous bug fix that caused this regression. The new version is already published to npm and should be available in the VS Code marketplace in the next few minutes and in pypi within the next 24 hours. Apologies for any inconvenience this caused.