Thomas M Kehrenberg

If the mistake is in a third-party library, does it still show an error in my own code? So, for example: `some_library/__init__.py`: ```python from dataclasses import dataclass, field from typing...

> It does show errors from third-party libraries, I assume we want to suppress those? Nevermind actually, I realized that a lot of other mypy checks have the same problem....

Hm, the problem is that mypy doesn't keep track of how the type of `meow(s)` was determined. It's just treated as a union type: ```python s: Union[int, str] = 's'...

It's defined here, but you're right that it's not documented anywhere: https://github.com/python/mypy/blob/83660d0ad72ab5a61cea5fe5955e66c33ef54111/mypy/options.py#L70-L73

Very strange error. If I had to guess, I'd say it has to do with the slightly weird signature of `.get()`: https://github.com/python/typeshed/pull/10294 You could try defining your own `.get()` as...

One big advantage of `X = TypeAliasType("X", ...)` over `X: TypeAlias = ...` is that you can choose the order of the type parameters: ```python from typing import TypeVar from...

Just for reference, this is likely due to #16942.

You get an error though if you try to call `.update()` from the first code snippet with an instance of `BaseClass` though. So I think that's safe enough? EDIT: I...

The problem is that mypy assumes that narrowed instance variables don't change their type even if (potentially mutating) methods are called: ```python class A: def __init__(self) -> None: self.x: int...

Sounds like the error code `explicit-override` from #15512 is being activated erroneously in the test stubs. Adding the `@override` decorators feels more like a work-around for that.