Unfriendly error messages

[vors]

This is a little bit of a wage question, but still want to ask it.
I'm trying to migrate to a newer version of pyright and the error messages are just hard to comprehend

Some examples

<redacted>/__init__.py:47:50 - error: Argument of type "str" cannot be assigned to parameter "__object" of type "_T@list" in function "append"

<redacted>.py:37:26 - error: Argument of type "Literal['a']" cannot be assigned to parameter "__key" of type "_KT@Mapping" in function "__getitem__"

Lots and lots of errors that mention generics... I'm considering myself reasonably educated about types, but I'm spending 10 minutes, 20 minutes looking into these errors, and I have no idea how to fix them 😆

So couple concrete questions:

• is there some documentation to help grok on these errors?
• maybe there is an opportunity for generally more user friendly error messages? I'd dig into any docs on it, but I have 100s of developers who probably would not.

[erictraut]

I'm open to suggestions for how to improve the error messages. For most of these messages, pyright already provides additional details that should help further clarify the top-level message. For example:

x = [1, 2, 3]
x.append("hello")

Error:

Argument of type "Literal['hello']" cannot be assigned to parameter "__object" of type "int" in function "append"
  "Literal['hello']" is incompatible with "int"

Do these additional details help?

[vors]

Is there some way to ask pyright to explain why it inferred a certain type? I work right now in a part of the codebase without much types and it's very non-obvious about the decisions on inference that are made.

[erictraut]

Asking how a type checker inferred a certain type is a very broad question. Perhaps there's a particular example you would like to ask about?

The high-level rules that pyright employs for inference are documented here.

When you say "inference", you might also be referring to "constraint solving", which is the process by which a type checker determines the type of a type variable. This behavior is mostly dictated by the rules of the Python type system, but there are areas of ambiguity where each type checker must supply its own heuristics. You can read about some of the more subtle differences between mypy and pyright here.

For a basic understanding of type variables and constraints, you may find this section of PEP 484 useful. The basic idea is that the type checker must find some type that satisfies all of the specified constraints. These constraints include things like "the final type must be a subtype of Foo" (a covariant constraint) or "Bar must be a subtype of the final type" (a contravariant constraint).