Jukka Lehtosalo

Here's a fifth way (an alternative to the `__getattr__` way): you could transform the test suite to record all attribute accesses. So each expression of form `x.y` would be transformed...

There probably isn't a reliable way of inferring all attributes. But I think that's fine; a 97% or 99% solution would still save a lot of effort. Besides, a lot...

Alternatively, use the keyword `sealed` instead of `final`.

> I worry, however, that there's not much point in annotating a variable as Literal or Final if it's automatically inferred as something less precise as soon as it's assigned...

> The statement x: Final = 3 tells a type checker that x is read-only, but it doesn't specify its type. A type checker must infer its type in this...

Another way to explain the mypy behavior is that explicit literal types are "sticky"/"strict" and don't get implicitly "weakened" into the underlying runtime type such as `str`. This allows precise...

> And indeed, there are no type safety issues here, but mypy emits three (what I would consider false positive) errors. These are working as designed. The relevant rules are...

> > Anyway, if different type checkers have interpreted PEP 586 differently, it seems to me that we should avoid using literal types in stubs in contexts where their semantics...

Technically, it would be easy to change mypy to support `x: Literal[42]` as an alias for `x: Final = 42` in stubs, but I prefer the `Final` approach, since it's...

`typeshed` is not specific to any tool. As PEP 484 doesn't spell out all details of how type checking should work, tools may make different interpretations and thus different annotations...