Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overload with variadic is not preferred over non-variadic #9748

Open
erictraut opened this issue Jan 23, 2025 · 0 comments
Open

Overload with variadic is not preferred over non-variadic #9748

erictraut opened this issue Jan 23, 2025 · 0 comments
Labels
addressed in next version Issue is fixed and will appear in next published version bug Something isn't working spec compliance

Comments

@erictraut
Copy link
Collaborator

erictraut commented Jan 23, 2025

The draft section on overload evaluation proposes the following rule:

# > Step 4: If the argument list is compatible with two or more overloads,
# > determine whether one or more of the overloads has a variadic parameter
# > (either ``*args`` or ``**kwargs``) that maps to a corresponding argument
# > that supplies an indeterminate number of positional or keyword arguments.
# > If so, eliminate overloads that do not have a variadic parameter.

Pyright doesn't currently enforce this rule in all cases.

@overload
def variadic(x: int, /) -> str:
    ...

@overload
def variadic(x: int, y: int, /, *args: int) -> int:
    ...

def variadic(*args: int) -> int | str:
    return 1

def check_variadic(v: list[int]) -> None:
    ret1 = variadic(*v)
    assert_type(ret1, int) # Failure
@erictraut erictraut added bug Something isn't working spec compliance labels Jan 23, 2025
erictraut added a commit that referenced this issue Jan 25, 2025
…roposed type specification rules regarding `*args` parameters. This addresses #9748.
erictraut added a commit that referenced this issue Jan 25, 2025
…roposed type specification rules regarding `*args` parameters. This addresses #9748. (#9760)
@erictraut erictraut added the addressed in next version Issue is fixed and will appear in next published version label Jan 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addressed in next version Issue is fixed and will appear in next published version bug Something isn't working spec compliance
Projects
None yet
Development

No branches or pull requests

1 participant