Carl Meyer

A subtype or assignability check would work fine here -- but in general `assert_type` requiring exact type equivalence makes it a little too sensitive to details of individual type checker...

I don't think we plan to change this behavior, but we can leave this open for now if there's more discussion needed about the value of compatibility with other type...

We also have a `TypeOf` helper in ty in our `ty_extensions` pseudo-module (doesn't exist at runtime, but ty always considers it to exist) that is useful for asserting about non-spellable...

> I noticed for example that ty requires `Literal` types on the right-hand-side in case of e.g `a = "b"; assert_type(a, ?)`, whereas for myrightfly that's be a plain `str`....

> Maybe if we infer a non-spellable subtype of the type you're asserting, we could emit a diagnostic with a different error code (which would have warn-level by default, rather...

Ah hm, that's interesting. I wonder why pyright goes with `str` in that case but `Literal["a"]` in the case of `a: str = "a"`... from ty's perspective they are the...

@DetachHead observes in #1495 that this also comes up with function-literal types: ```py def foo() -> None: ... assert_type(foo, Callable[[], None]) # error ```

@NickCrews Unfortunately I think that usage is not supported in the PEP, typing spec, or by other type checkers, so that would need discussion on discuss.python.org to reach consensus of...

Thanks -- I agree that we should emit a diagnostic on this program. There's two ways that might happen: one is discussed in #1515, which is that we'd have a...

There's also this dataclass-less version, which is a bit different in that it doesn't involve a synthesized `__init__` method, and which we also wrongly error on: ```py from typing import...