ruff

7d8c6422 - [ty] do not union Unknown into unannotated container types (#23718)

[ty] do not union Unknown into unannotated container types (#23718) ## Summary Part of https://github.com/astral-sh/ty/issues/1240 Stop unioning `Unknown` into the types of un-annotated container literals. We discussed perhaps continuing to union `Unknown` if the inferred type is a singleton type like `None`. I'd like to explore this as a separate change so we can see the ecosystem impact more clearly. ## Test Plan Adjusted many mdtest expectations. There's one test case that regresses with this change, because we don't fully support union type contexts (it can require a lot of repeat inference in pathological cases). So `x10: list[int | str] | list[int | None] = [1, 2, 3]` previously passed only because we inferred the RHS as `list[Unknown | int]` -- now we infer it as `list[int]` and the assignment fails due to invariance. I've kept this test as a TODO since it's not trivial to fix. Mypy errors in the same way we now do, suggesting it's not necessarily a huge priority either. ## Ecosystem This change is expected to cause new diagnostics and some false positives, since we are replacing very-forgiving gradual types with non-gradual inference heuristics. Many of these issues could be solved or significantly mitigated by https://github.com/astral-sh/ty/issues/1473, depending how far we are able to go with that, and particularly whether we can afford to apply it also to container literals which are not empty at construction. The downside of broad application of this approach is that in some cases it could cause us to widen container types when the user actually just made a mistake and added the wrong thing to a container, and would prefer an error at that location. Some categories of new error that show up in the ecosystem report: ### Implicit TypedDicts These are cases where the dictionary is heterogeneous and would ideally be typed as a `TypedDict` but isn't, for example: ```py def make_person(photo: bytes | None): person = {"name": "Pat", age: 29} if photo is not None: person["photo"] = photo ``` We (and pyrefly, and pyright in strict mode) error on the last line here because we already inferred `dict[str, str | int]`, so we can't add a `bytes` value. Mypy prefers common-base joins over union joins, so it infers `dict[str, object]`, which avoids the error adding a `bytes` value. This means the value type is less precise, which theoretically means potentially more errors using values from the dict later. But in practice with this heterogeneous pattern, either `object` or the union will cause similar problems when using values from the dict -- in either case you'd probably have to cast or narrow. Pyright (in non-strict mode) has a special case where it falls back to `Unknown` when it sees heterogenous value types, so it infers this as `dict[str, Unknown]`. I think we could consider either the mypy or pyright approaches here, but we don't need to do it in this PR; we can file an issue and consider it as a follow-up. Another symptom of this same root cause is repetitive diagnostics arising from a large union inferred as value type; the same fixes would address this. ### Negative intersections, particularly with e.g. `~AlwaysFalsy` or `~None`. Example: ```py class A: ... def _(a: A | None) -> dict[str, A]: if a: d = {"a": a} return d return {} ``` We error on `return d` because "expected `dict[str, A]`, found `dict[str, A & ~AlwaysFalsy]`". This is an issue specific to intersection types, so no other type checker has this problem. I think when we "promote literals" (we may need to give this operation a broader name -- it's really "type promotion to give a better inferred type when invariance means too-precise is bad") we should also eliminate all negative types from intersections. I would prefer to do this as a separate PR for easier review and better visibility of ecosystem impact, but I think it's high priority to land soon after this PR (ideally before a release). ### Overly-precise inference for singleton `None` This did show up, to the tune of ~100 new diagnostics ([example](https://github.com/pytorch/ignite/blob/b73a4c20e991b3e14949f2a69651ed2a7219f2fd/tests/ignite/engine/test_engine.py#L158)), so I think it is worth addressing as a follow-up.