Pyright expects an incorrect order of arguments for the init of multiple inheritance attr classes

[radugrosu]

import attr

@attr.s(auto_attribs=True)
class A:
    one: int

@attr.s(auto_attribs=True)
class B:
    two: str

@attr.s(auto_attribs=True)
class C(A, B):
    pass

C(1, "two")

produces for the line :

15:3 - error: Argument of type "Literal[1]" cannot be assigned to parameter "two" of type "str" in function "__init__"
    "Literal[1]" is incompatible with "str" (reportGeneralTypeIssues)
15:6 - error: Argument of type "Literal['two']" cannot be assigned to parameter "one" of type "int" in function "__init__"
    "Literal['two']" is incompatible with "int" 

when running the latest (pyright 1.1.338).

Expected behaviour is no warnings (the code is correct as is).

[erictraut]

Pyright has no specialized knowledge of attrs — or any other third-party library, for that matter. It bases its type analysis on the standard type information provided by the library author.

In this case, attrs uses a mechanism called dataclass_transform which was introduced to the Python type system in PEP 681. It supports libraries like attrs and pydantic, which act like the stdlib dataclass mechanism. When a library uses dataclass_transform, it's telling the type checker "treat me like dataclass and adopt all of its documented behaviors".

Unfortunately, it looks like attrs deviates from the behavior of dataclass when it comes to multiple inheritance. Even if you switch from @attr.s to @attr.dataclass, it still appears to deviate from the standard dataclass behavior.

If you want this to work with pyright, here are your options.

1. Consult with the attrs maintainers to see if there are any other options that get it to mirror the multiple inheritance behavior of dataclass
2. Switch from attrs to the stdlib dataclass
3. Use keyword arguments to specify the init parameters
4. Don't use multiple inheritance with attrs classes