ruff/crates/red_knot_python_semantic/resources/mdtest/generics
Douglas Creager 9db63fc58c
[red-knot] Handle generic constructors of generic classes (#17552)
We now handle generic constructor methods on generic classes correctly:

```py
class C[T]:
    def __init__[S](self, t: T, s: S): ...

x = C(1, "str")
```

Here, constructing `C` requires us to infer a specialization for the
generic contexts of `C` and `__init__` at the same time.

At first I thought I would need to track the full stack of nested
generic contexts here (since the `[S]` context is nested within the
`[T]` context). But I think this is the only way that we might need to
specialize more than one generic context at once — in all other cases, a
containing generic context must be specialized before we get to a nested
one, and so we can just special-case this.

While we're here, we also construct the generic context for a generic
function lazily, when its signature is accessed, instead of eagerly when
inferring the function body.
2025-04-23 15:06:18 -04:00
..
classes.md [red-knot] Handle generic constructors of generic classes (#17552) 2025-04-23 15:06:18 -04:00
functions.md [red-knot] Detect version-related syntax errors (#16379) 2025-04-17 14:00:30 -04:00
legacy.md Use python.typing.org for typing documentation links (#17323) 2025-04-09 20:38:20 +02:00
pep695.md [red-knot] Handle explicit class specialization in type expressions (#17434) 2025-04-18 11:49:22 -04:00
scoping.md [red-knot] Fix MRO inference for protocol classes; allow inheritance from subscripted Generic[]; forbid subclassing unsubscripted Generic (#17452) 2025-04-18 19:55:53 +00:00
variance.md [red-knot] Handle explicit class specialization in type expressions (#17434) 2025-04-18 11:49:22 -04:00