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.

Will this PR also fix #17564?

@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.

Thanks for explaining!

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

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