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.

Sign up for GitHub

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

Jump to bottom

Tuple size is lost while it can be deduced #6958

Closed
iyanging opened this issue Jan 11, 2024 · 3 comments
Closed

Tuple size is lost while it can be deduced #6958

iyanging opened this issue Jan 11, 2024 · 3 comments
Labels
addressed in next version Issue is fixed and will appear in next published version bug Something isn't working

Comments

@iyanging
Copy link

iyanging commented Jan 11, 2024 •
edited
Loading

Describe the bug
Tuple size is lost while it can be deduced.

Code or Screenshots

def hello(a: int) -> tuple[int, int, int]:
    r = (1, 2, 3, 4)
    if a > 0:
        return r[0:3]
    else:
        return r[1:4]
❯ pyright a.py
/Users/iyang/a.py
  /Users/iyang/a.py:6:16 - error: Expression of type "tuple[Literal[1, 2, 3, 4], ...]" cannot be assigned to return type "tuple[int, int, int]"
    "tuple[Literal[1, 2, 3, 4], ...]" is incompatible with "tuple[int, int, int]"
      Tuple size mismatch; expected 3 but received indeterminate (reportGeneralTypeIssues)
1 error, 0 warnings, 0 informations

VS Code extension or command-line

> pyright --version
pyright 1.1.345
@iyanging iyanging added the bug Something isn't working label Jan 11, 2024
@tsibley
Copy link

tsibley commented Jan 11, 2024 •
edited
Loading

I've also run into this where a tuple typed Tuple[str, int] | Tuple[str, int, int, int] sliced with [0:2] results in the revealed type tuple[str | int, ...] instead of tuple[str, int].

This was fine with 1.1.344.

tsibley added a commit to nextstrain/cli that referenced this issue Jan 11, 2024
@tsibley
dev: Appease Pyright 1.1.345's changed type checking of tuple slices
03108d0 
A slice like x[0:2] may evaluate to ('a',) or ('a', 'b',) depending on
the length of x.  Pyright changed its checking of this slice behaviour
for tuples in 1.1.345 (released 4 days ago)¹, which started raising
issues with this code in CI.

While we humans know that the sockaddr tuples here always have at least
two elements, Pyright does not.  I think Pyright could do better here as
it knows the type of sockaddr is

    Tuple[str, int] | Tuple[str, int, int, int]

and thus I think should be able to know for sure the type of a 0:2
slice.  Instead, it evaluates the slice type to an ambiguous

    Tuple[str | int, ...]

which is incompatible with the declared return type.

I went to report this behaviour regression, but someone beat me to it:
<microsoft/pyright#6958>.

¹ <https://github.com/microsoft/pyright/releases/tag/1.1.345>
tsibley added a commit to nextstrain/cli that referenced this issue Jan 11, 2024
@tsibley
dev: Appease Pyright 1.1.345's changed type checking of tuple slices
67adaaf 
A slice like x[0:2] may evaluate to ('a',) or ('a', 'b',) depending on
the length of x.  Pyright changed its checking of this slice behaviour
for tuples in 1.1.345 (released 4 days ago)¹, which started raising
issues with this code in CI.

While we humans know that the sockaddr tuples here always have at least
two elements, Pyright does not.  I think Pyright could do better here as
it knows the type of sockaddr is

    Tuple[str, int] | Tuple[str, int, int, int]

and thus I think should be able to know for sure the type of a 0:2
slice.  Instead, it evaluates the slice type to an ambiguous

    Tuple[str | int, ...]

which is incompatible with our declared return type.

I went to report this behaviour regression, but someone's already beat
me to it.²

¹ <https://github.com/microsoft/pyright/releases/tag/1.1.345>
² <microsoft/pyright#6958>
@tsibley tsibley mentioned this issue Jan 11, 2024
Merged
1 task
erictraut added a commit that referenced this issue Jan 11, 2024
@erictraut
Fixed a bug that resulted in an incorrect type evaluation for a slice…
89cef4e 
…d tuple if the end of the slice is the same as the tuple length (off-by-one error). This addresses #6958.
@erictraut
Copy link
Collaborator

Thanks for the bug report. This was an off-by-one error in my logic — and a hole in (what was otherwise an extensive) test suite. This will be fixed in the next release.

@erictraut erictraut added the addressed in next version Issue is fixed and will appear in next published version label Jan 11, 2024
@erictraut
Copy link
Collaborator

This is included in pyright 1.1.346, which I just published. It will also be included in a future release of pylance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
addressed in next version Issue is fixed and will appear in next published version bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@tsibley @erictraut @iyanging