Repository navigation
Combine starred element types in unpacking #191
Description
Activity
- changed the title
[-]Combine starred element types. For example, in `(a, *b, c) = (1, 2, 3, 4)`, the `Literal[2]` and `Literal[3]` type should be combined into `list[int]` to be assigned to `*b`. **(Requires generic support over list)** https://github.com/astral-sh/ruff/blob/c6b311c54643c039d793fb836caf94d22f03cbb4/crates/red_knot_python_semantic/src/types/infer.rs#L1248-L1251[/-][+][red-knot] Combine starred element type in unpacking[/+]on Feb 25, 2025 - changed the title
[-][red-knot] Combine starred element type in unpacking[/-][+][red-knot] Combine starred element types in unpacking[/+]on Feb 25, 2025 (Moving this to Backlog as it requires generic support over list)
Reacted by Carl Meyer- changed the title
[-][red-knot] Combine starred element types in unpacking[/-][+]Combine starred element types in unpacking[/+]on May 7, 2025 I think now that we have generic list, this should be pretty easy?
#247 (comment) gave this example:
error[unresolved-attribute]: Type `str` has no attribute `pop` --> src/eulertools/lib/utils.py:383:18 | 381 | prefix, response_key, *answers = line.split(maxsplit=2) 382 | try: 383 | answer = answers.pop() | ^^^^^^^^^^^ 384 | except IndexError: 385 | answer = "" | info: rule `unresolved-attribute` is enabled by defaultIt seems to be this issue, though I'm surprised we wrongly infer
strhere rather than just inferringUnknownorTodo.Yes, this should be easy now. I do have a couple of questions:
-
What should we infer in this error case? Should it be
Unknownorlist[Unknown? I think the latter makes sense# error: [invalid-assignment] "Not enough values to unpack: Expected 3 or more" [a, *b, c, d] = (1, 2) reveal_type(a) # revealed: Unknown # TODO: Should be list[Any] once support for assigning to starred expression is added reveal_type(b) # revealed: Unknown reveal_type(c) # revealed: Unknown reveal_type(d) # revealed: Unknown
-
Should the literal types be promoted? In this example, should the inferred type be
list[Literal[2]]orlist[int]?[a, *b, c] = (1, 2, 3) reveal_type(a) # revealed: Literal[1] # TODO: Should be list[int] once support for assigning to starred expression is added reveal_type(b) # revealed: @Todo(starred unpacking) reveal_type(c) # revealed: Literal[3]
-
If we do promote the literal types, it would have a side effect in this example that we infer
list[str]instead oflist[LiteralString](a, *b, c) = "ab" reveal_type(a) # revealed: LiteralString # TODO: Should be list[LiteralString] once support for assigning to starred expression is added reveal_type(b) # revealed: @Todo(starred unpacking) reveal_type(c) # revealed: LiteralString
-
Re (1), I don't think it's hugely consequential either way, but I agree that if all else is equal,
list[Unknown]is preferable.Re (2), I would be inclined to initially not promote literals and see if it causes issues in practice. I suspect it's unusual to mutate an unpacked list, but I could be wrong.
Reacted by Dhruv Manilawala- added a commit that references this issue
on Jun 3, 2025 - added a commit that references this issue
on May 1, 2026 - added a commit that references this issue
on Aug 28, 2026
Combine starred element types. For example, in
(a, *b, c) = (1, 2, 3, 4), theLiteral[2]andLiteral[3]type should be combined intolist[int]to be assigned to*b. (Requires generic support over list) https://github.com/astral-sh/ruff/blob/c6b311c54643c039d793fb836caf94d22f03cbb4/crates/red_knot_python_semantic/src/types/infer.rs#L1248-L1251