false negative?: unpacking Iterable to fixed length positional arguments

[pinterior]

current Pyright (1.1.374) does not generate errors for unpacking Iterable to fixed length arguments.
i think it could be helpful if errors reported.

simple case

from collections.abc import Iterable
def f(): pass
def g(x: Iterable[str]): f(*x)

pyright-play.net

common typo case

function forwarding kwargs, but mistyped ** to *.

from typing import TypedDict, Unpack

class A(TypedDict, total=False):
    x: int

def f(**kwargs: Unpack[A]):
    pass

def g(**kwargs: Unpack[A]):
    f(*kwargs)  # common typo: single asterisk

g(x=3)  # TypeError: f() takes 0 positional arguments but 1 was given

pyright-play.net

[erictraut]

This behavior is intended, so I don't consider this a bug. The python typing spec does not specify whether a type checker should generate an error when using an unpack operator on an operand of unknown length. This is a behavior that should arguably be specified one way or another in the spec, but currently it is not. Pyright's current behavior is based on two principles:

1. When code is potentially correct but also potentially a bug, pyright opts to avoid a false positive over a false negative. In this case, there's a false negative, but reporting this condition would result in false positives in valid Python code.
2. Unless there's good reason to deviate from behaviors established by mypy, pyright sticks to mypy's behaviors. Mypy doesn't generate an error, at least in the first "simple case" example. It does generate an error in your second example, but that means mypy is internally inconsistent. I'm not sure what principle it is using here.

For these reasons, I don't plan to modify the behavior here — at least not now. If the typing spec is updated or there is some consensus in the community that this condition should generate a type error, I'm open to changing this behavior. If you'd like to start a discussion about this, I recommend posting to the Python typing forum.

[pinterior]

I see. Thank you.