Cyclic0007/ruff
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[red-knot] Empty tuple is always-falsy (#17213)

Browse Source 
## Summary

Fix assignability of `tuple[()]` to `AlwaysFalsy`.

closes #17202 

## Test Plan

Ran the property tests for a while
This commit is contained in:
David Peter
2025-04-04 22:00:28 +02:00
committed by GitHub
parent b3243b5e2a
commit 1a6a10b30f
2 changed files with 16 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
crates/red_knot_python_semantic/resources/mdtest/type_properties/is_assignable_to.md
View File

@@ -183,7 +183,7 @@ static_assert(is_assignable_to(Meta, type[Unknown]))
## Tuple types
```py
from knot_extensions import static_assert, is_assignable_to
from knot_extensions import static_assert, is_assignable_to, AlwaysTruthy, AlwaysFalsy
from typing import Literal, Any
static_assert(is_assignable_to(tuple[()], tuple[()]))
@@ -198,6 +198,14 @@ static_assert(is_assignable_to(tuple[()], tuple))
static_assert(is_assignable_to(tuple[int, str], tuple))
static_assert(is_assignable_to(tuple[Any], tuple))
# TODO: It is not yet clear if we want the following two assertions to hold.
# See https://github.com/astral-sh/ruff/issues/15528 for more details. The
# short version is: We either need to special-case enforcement of the Liskov
# substitution principle on `__bool__` and `__len__` for tuple subclasses,
# or we need to negate these assertions.
static_assert(is_assignable_to(tuple[()], AlwaysFalsy))
static_assert(is_assignable_to(tuple[int], AlwaysTruthy))
static_assert(not is_assignable_to(tuple[()], tuple[int]))
static_assert(not is_assignable_to(tuple[int], tuple[str]))
static_assert(not is_assignable_to(tuple[int], tuple[int, str]))