attrs deviation from PEP 681

[alonme]

According to the Pylance developers attrs deviates from PEP 681 in the way it treats kw_only in field override
microsoft/pylance-release#4670

[radugrosu]

probably related: microsoft/pyright#6572

[alonme]

Hey @hynek,

What are your thoughts around this issue?
Is this breaking change something that you are willing to change in attrs?
Are contributions to solve this issue welcome?

[hynek]

I don’t think those two issues are related.

The Pyright issue is that dataclasses implement the MRO wrong which becomes obvious with multiple inheritance. To be fair, it might’ve copied it from early attrs versions that did it wrong too. Changing that would be a very hard backwards-compatibility breakage in addition to plainly wrong. It's the default in @attr.s. Generally speaking, design-wise I think the advice to only use kwargs in such hierarchies is probably the best.

My understanding of the kw_only issue seems like dataclasses inherit fields configuration?? Do they do that for all config? There’s a bunch of issues around this topic here that went nowhere so far. I could imagine adding an inherit_fields option to define, but I’m not sure if that would help you since it still requires you to pass additional arguments. Cc @Tinche

I think there even was an issue asking for a dataclass compat API so I guess we could reimplement some their bugs within our @dataclass Easter egg too if there’s enough interest.

---

I’m sorry by not being responsive here, but I get angry whenever I re-read the pontification of how we implement a PEP wrong which has been written long after attrs was implemented and that was the only way for us to get any Pylance/Pyright support whatsoever. We had no choice in this matter and did our best to cooperate and them pointing fingers at us now for not breaking our users doesn't feel great.

[asford]

Drive-by cross-referencing...

#565
#686

are prior issues on the "attrs-is-dataclasses-plus" namespace.