Skip to content

Fix inferred type of a tuple indexed by a slice value#21721

Open
apoorva-01 wants to merge 1 commit into
python:masterfrom
apoorva-01:fix-21708-tuple-slice-index
Open

Fix inferred type of a tuple indexed by a slice value#21721
apoorva-01 wants to merge 1 commit into
python:masterfrom
apoorva-01:fix-21708-tuple-slice-index

Conversation

@apoorva-01

Copy link
Copy Markdown

Fixes #21708

(1, 2, 3)[s] with s: slice came out as int, but it's a tuple at runtime and a.__getitem__(s) already gets tuple[int, ...] right. The subscript code only spotted a slice written as t[1:2] (a SliceExpr); a slice variable is a plain NameExpr, so it fell through to the int-index branch. Now it checks the index type too.

Test added next to testNonliteralTupleSlice, fails on the old code. Left the int | slice union case alone, it still gives the item type.

The subscript path only treated literal slice syntax as a slice, so `t[s]`
with `s: slice` fell through to the int-index result instead of tuple[...].

Fixes python#21708.
@github-actions

Copy link
Copy Markdown
Contributor

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Wrong type inference for <tuple>[s] where s: slice

1 participant