Allow subclasses of a dataclass to define required fields when a parent has defined optional fields

[felipe-m-morais]

Feature or enhancement

Proposal:

Although this is something that can be worked around by defining the optional fields as kw_only, that has the onus of forcing the instantiation of the parent classes to be more verbose. Instead, I propose to simply adjust the order of the fields: just like they are already reordered to move kw_only fields to the back, we need only move fields that define a default/default_factory to the front. The fix is so simple it could be done in the same function with minor changes:

# Current:
def _fields_in_init_order(fields):
    # Returns the fields as __init__ will output them.  It returns 2 tuples:
    # the first for normal args, and the second for keyword args.

    return (tuple(f for f in fields if f.init and not f.kw_only),
            tuple(f for f in fields if f.init and f.kw_only)
            )

# Proposed:
def _fields_in_init_order(fields):
    # Returns the fields as __init__ will output them.  It returns 2 tuples:
    # the first for normal args, and the second for keyword args.
    
    required_fields = []
    optional_fields = []
    kw_fields = []
    for f in fields:
        if not f.init:
            continue
        if f.kw_only:
            kw_fields.append(f)
        elif f.default is MISSING and f.default_factory is MISSING:
            required_fields.append(f)
        else:
            optional_fields.append(f)

    return tuple(required_fields + optional_fields), tuple(kw_fields)

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

[LukeGrochocki]

I'll go ahead and work on this.

[sobolevn]

Allow subclasses of a dataclass to define required fields when a parent has defined optional fields

Techincally this would break the subtyping:

>>> from dataclasses import dataclass
>>> @dataclass
... class A:
...    x: int = 0
...    
>>> @dataclass
... class B(A):
...    x: int
...
>>> def some() -> type[A]:
...    return B
...    
>>> some()()
TypeError: B.__init__() missing 1 required positional argument: 'x'

Since A can be created with just () and B now needs (x: int)

[ericvsmith]

As this is a feature request, please open a discussion on discuss.python.org. If it is accepted there, we can then reopen this issue. I haven’t had time to think about it, but if it is not backward compatible, then there’s not much chance it will be accepted.

[felipe-m-morais]

Allow subclasses of a dataclass to define required fields when a parent has defined optional fields

Techincally this would break the subtyping:

from dataclasses import dataclass
@DataClass
... class A:
... x: int = 0
...
@DataClass
... class B(A):
... x: int
...
def some() -> type[A]:
... return B
...
some()()
TypeError: B.init() missing 1 required positional argument: 'x'
Since A can be created with just () and B now needs (x: int)

I just ran this on Python 3.11.9 and it raised no errors on either the original or proposed version.

[felipe-m-morais]

As this is a feature request, please open a discussion on discuss.python.org. If it is accepted there, we can then reopen this issue. I haven’t had time to think about it, but if it is not backward compatible, then there’s not much chance it will be accepted.

I'd be happy to, but as this is my first time attempting to contribute, do you mind clarifying (or linking to a definition) of feature request / backward compatibility? I realise I'm the one who added the feature label, but when I think about it, maybe it would be better described as a bug fix - here's why with a better example:

from dataclasses import dataclass

@dataclass
class Parent:
    a: int
    b: str = ""

# this raises an error currently (TypeError: non-default argument 'c' follows default argument)
# I *think* it should work, since it's pretty straightforward, and it would work with my proposed change
@dataclass
class Child(Parent):
    c: float
    d: bool = False

To the best of my knowledge, the only implication of what I'm proposing is that this error would not be raised as often - it shouldn't break or alter any code implementing valid dataclasses. Currently, to implement the Child class, I need to do:

@dataclass
class ChildRequired:
    c: float
    
@dataclass
class ChildOptional:
    d: bool = False

@dataclass
class Child(ChildOptional, Parent, ChildRequired):
    pass

[ericvsmith]

For backward compatibility: does it break existing working code? I’m on vacation and won’t have time to look into it for a while, thus my comment above.

As for is it a feature request: it’s a judgement call. In general, more people will see it on d.p.o., and I’d prefer that this have more eyeballs on it. And I’m the one who gets to make the call on dataclasses features!