Should we consider this a bugfix or a feature actually? (to determine whether it requires backports or not, and update the issue's labels, which I tagged as 3.12, 3.13 and 3.14 + bug).

Friendly ping @ericvsmith

For example, it can break abstract dataclasses, which do not have init on purpose. And their subclasses have __init__s

That's something I entirely missed. Maybe we can work out by checking if the class is abstract (namely, declared using abc.ABC or metaclass=abc.ABCMeta) and do not raise in this case? Otherwise we can drop this behaviour.

Anyway, this solves one of my question about whether this is a bug fix or a feature. Since it could break something, whether we want it or not, I'd prefer tagging it as a feature rather than a bug fix.

@ericvsmith friendly ping

I don't think I'll land this one because of this:

For example, it can break abstract dataclasses, which do not have __init__ on purpose. And their subclasses have __init__s.

To be clear, it makes sense to indeed have an error but it's hard to know whether the error should be pre-caught as there are cases where it can be said that it would be unreachable (namely, we expect concrete classes to have their own __init__ and deal with what they need to I guess?).

So I'll mark this one as stale and a draft as I need to add tests for abstract classes as well..