Assigning a non-string to Class.__name__ gives a confusing error

[Jackenmen]

Describe the bug
Setting Class.__name__ to something that is not a string gives a confusing error.

To Reproduce

1. Put code from "Screenshots or Code" into a file.
2. Run pyright on it.
3. See results:

No configuration file found.
No pyproject.toml file found.
stubPath /tmp/typings is not a valid directory.
Assuming Python platform Linux
Searching for source files
Found 1 source file
pyright 1.1.271
/tmp/example.py
  /tmp/example.py:5:9 - error: Cannot assign member "__name__" for type "Type[Example]"
    Member "__name__" is unknown (reportGeneralTypeIssues)
1 error, 0 warnings, 0 informations 
Completed in 0.662sec

Expected behavior
I expected the error to be something like:

/tmp/example.py
  /tmp/example.py:5:9 - error: Cannot assign member "__name__" for type "Type[Example]"
    Expression of type "Literal[123]" cannot be assigned to member "__name__" of class "Example"
      "Literal[123]" is incompatible with "str" (reportGeneralTypeIssues)

Screenshots or Code

class Example:
    ...


Example.__name__ = 123

VS Code extension or command-line
I'm running pyright 1.1.271 from CLI.

Additional context
N/A

[erictraut]

Yes, this error message is confusing. Here's what's happening. When assigning a value to an attribute of a class, pyright needs to first check whether there is a declared class variable by that name associated with the class or one of its ancestors. If not, it then needs to see if there's an attribute associated with the metaclass and, if so, determine whether the assigned value is compatible with its type. In this case, there is no attribute __name__ associated with the class Example, so pyright fails the first check and records the diagnostic message "Member 'name' is unknown". It then checks the metaclass and finds an attribute __name__, but it fails the type compatibility check since you're attempting to assign an int value to a str attribute. It then reports the failure but uses the error message from the first check.

I've updated the code to disambiguate between these two checks and report the appropriate error. This fix will be in the next release.

[erictraut]

This is addressed in pyright 1.1.272. It will also be included in a future release of pylance.