Typing conformance results

No changes detected ✅

Memory usage report

Memory usage unchanged ✅

mypy_primer results

scikit-build-core (https://github.com/scikit-build/scikit-build-core)
+ src/scikit_build_core/build/wheel.py:99:20: error[no-matching-overload] No overload of bound method `__init__` matches arguments
- Found 59 diagnostics
+ Found 60 diagnostics

core (https://github.com/home-assistant/core)
- homeassistant/helpers/discovery_flow.py:59:19: error[invalid-assignment] Object of type `dict[str, object]` is not assignable to `ConfigFlowContext`
- Found 12092 diagnostics
+ Found 12091 diagnostics

Oh sorry, my impression was the prior approach was way off. Let me revisit.

Okay, I looked at #23408 again (and updated the relevant branch). The problem is, if we just add the synthesized method, we still see this behavior:

from typing import TypedDict

class MyDict(TypedDict):
    foo: int
    bar: str

val = MyDict(foo=1, bar="hello")
result = val | {"foo": 2}
reveal_type(result)  # dict[str, object], but should be MyDict

Because {"foo": 2} is inferred as dict[str, int], which hits the dict[str, Any] -> dict[str, object] fallback. So we still need some changes to these codepaths to add some amount of bidirectional inference, IIUC.

The resulting diff ends up being similar, except we have a synthesized method instead of:

(Type::TypedDict(left_typed_dict), rhs, ast::Operator::BitOr)
    if rhs.is_assignable_to(db, Type::TypedDict(left_typed_dict)) =>
{
    Some(Type::TypedDict(left_typed_dict))
}

(lhs, Type::TypedDict(right_typed_dict), ast::Operator::BitOr)
    if lhs.is_assignable_to(db, Type::TypedDict(right_typed_dict)) =>
{
    Some(Type::TypedDict(right_typed_dict))
}

To me, this approach seems a little better given the above.

The advantage of the synthesized-method approach is that these tests, which fail on your branch, would (I think) naturally pass:

from typing import TypedDict, Protocol, Self

class Foo(TypedDict):
    x: str
    y: int

class Bar(TypedDict, closed=True):
    x: str

def _(f: Foo, g: Bar):
    f |= g  # errors on this branch, but should pass

class Proto(Protocol):
    def __or__(self, other: Bar) -> Self: ...

def takes_proto(x: Proto): ...

def test(x: Foo):
    takes_proto(x)  # errors on this branch, but should pass

And I suspect we will have to add bidirectional inference for __(r)or__ calls anyway at some point, much like we already have for other dunders, such as __setitem__?

Okay, let me update this branch to use the synthesized approach and add those tests.

BTW, in the updated implementation, I actually needed three overloads...

def __or__(self: Self, value: Self, /) -> Self
def __or__(self: Self, value: Partial[Self], /) -> Self
def __or__(self: Self, value: dict[str, Any], /) -> dict[str, object]

Where Partial[Self] is Self with every field made NotRequired.

If you only have the first and third overload, then partial dicts on the RHS aren't accepted. If you only have the second and third, then if Self has a required field, the TypedDict itself isn't accepted on the RHS.

Ah, hmm... can those first two overloads be combined?

def __or__(self: Self, value: Self | Partial[Self], /) -> Self
def __or__(self: Self, value: dict[str, Any], /) -> dict[str, object]

Yeah this one is getting quite challenging to get right everywhere.