Eric Traut

Since this was originally opened, protocols have been added to the type system. Here's a solution to Jukka's original problem using a protocol with a partial implementation. It enforces that...

I think what's confusing mypy is the fact that `cs` has a default argument in overloads 3 and 4. We can eliminate that requirement if `i1` and `cs` are keyword-only...

I would be opposed to checking for errors that are specific to other type checkers within pyright. PEP 484 is pretty clear — a `# type: ignore` is supposed to...

Mypy 1.5 appears to support `StrEnum`. Is there anything left to do, or can this be closed?

For details about areas where pyright intentionally differs from mypy, you may find [this documentation](https://microsoft.github.io/pyright/#/mypy-comparison?id=type-checking-unannotated-code) interesting.

If [PEP 712](https://peps.python.org/pep-0712/) is accepted and implemented in mypy, this functionality will come "for free" because `attrs` uses `dataclass_transform`.

A similar question was recently posted to the [pyright issue tracker](https://github.com/microsoft/pyright/issues/7179). From my perspective, this is a legitimate use of pattern matching. Pyright therefore does not generate a type error...

This bug appears to have been fixed in mypy 1.4.0.

`_T` in your first code sample is properly bound to `__init__`, so this isn't technically an error condition, at least not like the other errors you mentioned where the type...

> It is no different from explicitly annotating foo: _T and bar: _T in a dataclass, isn't it? I think these are different cases. Case 1: A reference to an...