Move dataclass kw_only fields to the end of the signature

[sterliakov]

Fixes #19017. Fixes #17731.

This is a rather naive change: python does that at runtime. kw_only args can be in any order, and non-kwonly args should remain sorted as-is (stable sort). I don't understand why this was only done in presence of a parent dataclass - AFAIC kwonly fields work that way since kw_only was introduced in py3.10.

The test I changed was invalid and asserted a false positive to the best of my knowledge.

[A5rocks]

I find the found_dataclass_supertype logic confusing -- why was that there?

Because this makes sense.

[sterliakov]

Given that we had a test asserting such behavior, I suspect #13539 was just a rushed implementation with some cases mistreated or misunderstood. I can't find any explanation to sorting the attributes only if there was a parent class - perhaps the author assumed that kw_only fields must be in trailing positions only and consequently skipped sorting as a perf optimization.

[NeilGirdhar]

Will this PR also fix #17564?

[sterliakov]

@NeilGirdhar

No, it won't, because x is kn_only there and y is not, it's still sorted the wrong way... So we can't sort attributes once and forever, they may have different order in __init__ and __post_init__. The generated signatures in your example should be

# Follows the "jumping" logic of kw_only
def __init__(self, y: str, *, x: int): ...
# Definition order, reverse MRO order, no keywords
def __post_init__(self, x: int, y: str, /): ...

(a bit more difficult with defaults, but similar still)

Wait, I'm still confused. I'll look deeper into runtime behaviour of InitVar and inheritance tonight. No, that's right, InitVars just aren't affected by their kn_only-ness, since __post_init__ is posonly. That makes sense.

[NeilGirdhar]

Thanks for explaining!

[sterliakov]

#17564 is an easy fix, let's merge this and I will open a follow-up PR.

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅