The way dataclasses combines attributes prevents you from being able to use attributes with defaults in a base class and then use attributes without a default (positional attributes) in a subclass.

That's because the attributes are combined by starting from the bottom of the MRO, and building up an ordered list of the attributes in first-seen order; overrides are kept in their original location. So Parent starts out with ['name', 'age', 'ugly'], where ugly has a default, and then Child adds ['school'] to the end of that list (with ugly already in the list). This means you end up with ['name', 'age', 'ugly', 'school'] and because school doesn't have a default, this results in an invalid argument listing for __init__.

This is documented in PEP-557 Dataclasses, under inheritance:

When the Data Class is being created by the @dataclass decorator, it looks through all of the class's base classes in reverse MRO (that is, starting at object) and, for each Data Class that it finds, adds the fields from that base class to an ordered mapping of fields. After all of the base class fields are added, it adds its own fields to the ordered mapping. All of the generated methods will use this combined, calculated ordered mapping of fields. Because the fields are in insertion order, derived classes override base classes.

and under Specification:

TypeError will be raised if a field without a default value follows a field with a default value. This is true either when this occurs in a single class, or as a result of class inheritance.

You do have a few options here to avoid this issue.

The first option is to use separate base classes to force fields with defaults into a later position in the MRO order. At all cost, avoid setting fields directly on classes that are to be used as base classes, such as Parent.

The following class hierarchy works:

# base classes with fields; fields without defaults separate from fields with.
@dataclass
class _ParentBase:
    name: str
    age: int
    
@dataclass
class _ParentDefaultsBase:
    ugly: bool = False

@dataclass
class _ChildBase(_ParentBase):
    school: str

@dataclass
class _ChildDefaultsBase(_ParentDefaultsBase):
    ugly: bool = True

# public classes, deriving from base-with, base-without field classes
# subclasses of public classes should put the public base class up front.

@dataclass
class Parent(_ParentDefaultsBase, _ParentBase):
    def print_name(self):
        print(self.name)

    def print_age(self):
        print(self.age)

    def print_id(self):
        print(f"The Name is {self.name} and {self.name} is {self.age} year old")

@dataclass
class Child(_ChildDefaultsBase, Parent, _ChildBase):
    pass

By pulling out fields into separate base classes with fields without defaults and fields with defaults, and a carefully selected inheritance order, you can produce an MRO that puts all fields without defaults before those with defaults. The reversed MRO (ignoring object) for Child is:

_ParentBase
_ChildBase
_ParentDefaultsBase
Parent
_ChildDefaultsBase

Note that while Parent doesn't set any new fields, it does inherit the fields from _ParentDefaultsBase and should not end up 'last' in the field listing order; the above order puts _ChildDefaultsBase last so its fields 'win'. The dataclass rules are also satisfied; the classes with fields without defaults (_ParentBase and _ChildBase) precede the classes with fields with defaults (_ParentDefaultsBase and _ChildDefaultsBase).

The result is Parent and Child classes with a sane field older, while Child is still a subclass of Parent:

>>> from inspect import signature
>>> signature(Parent)
<Signature (name: str, age: int, ugly: bool = False) -> None>
>>> signature(Child)
<Signature (name: str, age: int, school: str, ugly: bool = True) -> None>
>>> issubclass(Child, Parent)
True

and so you can create instances of both classes:

>>> jack = Parent('jack snr', 32, ugly=True)
>>> jack_son = Child('jack jnr', 12, school='havard', ugly=True)
>>> jack
Parent(name='jack snr', age=32, ugly=True)
>>> jack_son
Child(name='jack jnr', age=12, school='havard', ugly=True)

Another option is to only use fields with defaults; you can still make in an error to not supply a school value, by raising one in __post_init__:

_no_default = object()

@dataclass
class Child(Parent):
    school: str = _no_default
    ugly: bool = True

    def __post_init__(self):
        if self.school is _no_default:
            raise TypeError("__init__ missing 1 required argument: 'school'")

but this does alter the field order; school ends up after ugly:

<Signature (name: str, age: int, ugly: bool = True, school: str = <object object at 0x1101d1210>) -> None>

and a type hint checker will complain about _no_default not being a string.

You can also use the attrs project, which was the project that inspired dataclasses. It uses a different inheritance merging strategy; it pulls overridden fields in a subclass to the end of the fields list, so ['name', 'age', 'ugly'] in the Parent class becomes ['name', 'age', 'school', 'ugly'] in the Child class; by overriding the field with a default, attrs allows the override without needing to do a MRO dance.

attrs supports defining fields without type hints, but lets stick to the supported type hinting mode by setting auto_attribs=True:

import attr

@attr.s(auto_attribs=True)
class Parent:
    name: str
    age: int
    ugly: bool = False

    def print_name(self):
        print(self.name)

    def print_age(self):
        print(self.age)

    def print_id(self):
        print(f"The Name is {self.name} and {self.name} is {self.age} year old")

@attr.s(auto_attribs=True)
class Child(Parent):
    school: str
    ugly: bool = True
Answer from Martijn Pieters on Stack Overflow
Top answer
1 of 16
397

The way dataclasses combines attributes prevents you from being able to use attributes with defaults in a base class and then use attributes without a default (positional attributes) in a subclass.

That's because the attributes are combined by starting from the bottom of the MRO, and building up an ordered list of the attributes in first-seen order; overrides are kept in their original location. So Parent starts out with ['name', 'age', 'ugly'], where ugly has a default, and then Child adds ['school'] to the end of that list (with ugly already in the list). This means you end up with ['name', 'age', 'ugly', 'school'] and because school doesn't have a default, this results in an invalid argument listing for __init__.

This is documented in PEP-557 Dataclasses, under inheritance:

When the Data Class is being created by the @dataclass decorator, it looks through all of the class's base classes in reverse MRO (that is, starting at object) and, for each Data Class that it finds, adds the fields from that base class to an ordered mapping of fields. After all of the base class fields are added, it adds its own fields to the ordered mapping. All of the generated methods will use this combined, calculated ordered mapping of fields. Because the fields are in insertion order, derived classes override base classes.

and under Specification:

TypeError will be raised if a field without a default value follows a field with a default value. This is true either when this occurs in a single class, or as a result of class inheritance.

You do have a few options here to avoid this issue.

The first option is to use separate base classes to force fields with defaults into a later position in the MRO order. At all cost, avoid setting fields directly on classes that are to be used as base classes, such as Parent.

The following class hierarchy works:

# base classes with fields; fields without defaults separate from fields with.
@dataclass
class _ParentBase:
    name: str
    age: int
    
@dataclass
class _ParentDefaultsBase:
    ugly: bool = False

@dataclass
class _ChildBase(_ParentBase):
    school: str

@dataclass
class _ChildDefaultsBase(_ParentDefaultsBase):
    ugly: bool = True

# public classes, deriving from base-with, base-without field classes
# subclasses of public classes should put the public base class up front.

@dataclass
class Parent(_ParentDefaultsBase, _ParentBase):
    def print_name(self):
        print(self.name)

    def print_age(self):
        print(self.age)

    def print_id(self):
        print(f"The Name is {self.name} and {self.name} is {self.age} year old")

@dataclass
class Child(_ChildDefaultsBase, Parent, _ChildBase):
    pass

By pulling out fields into separate base classes with fields without defaults and fields with defaults, and a carefully selected inheritance order, you can produce an MRO that puts all fields without defaults before those with defaults. The reversed MRO (ignoring object) for Child is:

_ParentBase
_ChildBase
_ParentDefaultsBase
Parent
_ChildDefaultsBase

Note that while Parent doesn't set any new fields, it does inherit the fields from _ParentDefaultsBase and should not end up 'last' in the field listing order; the above order puts _ChildDefaultsBase last so its fields 'win'. The dataclass rules are also satisfied; the classes with fields without defaults (_ParentBase and _ChildBase) precede the classes with fields with defaults (_ParentDefaultsBase and _ChildDefaultsBase).

The result is Parent and Child classes with a sane field older, while Child is still a subclass of Parent:

>>> from inspect import signature
>>> signature(Parent)
<Signature (name: str, age: int, ugly: bool = False) -> None>
>>> signature(Child)
<Signature (name: str, age: int, school: str, ugly: bool = True) -> None>
>>> issubclass(Child, Parent)
True

and so you can create instances of both classes:

>>> jack = Parent('jack snr', 32, ugly=True)
>>> jack_son = Child('jack jnr', 12, school='havard', ugly=True)
>>> jack
Parent(name='jack snr', age=32, ugly=True)
>>> jack_son
Child(name='jack jnr', age=12, school='havard', ugly=True)

Another option is to only use fields with defaults; you can still make in an error to not supply a school value, by raising one in __post_init__:

_no_default = object()

@dataclass
class Child(Parent):
    school: str = _no_default
    ugly: bool = True

    def __post_init__(self):
        if self.school is _no_default:
            raise TypeError("__init__ missing 1 required argument: 'school'")

but this does alter the field order; school ends up after ugly:

<Signature (name: str, age: int, ugly: bool = True, school: str = <object object at 0x1101d1210>) -> None>

and a type hint checker will complain about _no_default not being a string.

You can also use the attrs project, which was the project that inspired dataclasses. It uses a different inheritance merging strategy; it pulls overridden fields in a subclass to the end of the fields list, so ['name', 'age', 'ugly'] in the Parent class becomes ['name', 'age', 'school', 'ugly'] in the Child class; by overriding the field with a default, attrs allows the override without needing to do a MRO dance.

attrs supports defining fields without type hints, but lets stick to the supported type hinting mode by setting auto_attribs=True:

import attr

@attr.s(auto_attribs=True)
class Parent:
    name: str
    age: int
    ugly: bool = False

    def print_name(self):
        print(self.name)

    def print_age(self):
        print(self.age)

    def print_id(self):
        print(f"The Name is {self.name} and {self.name} is {self.age} year old")

@attr.s(auto_attribs=True)
class Child(Parent):
    school: str
    ugly: bool = True
2 of 16
191

Note that with Python 3.10, it is now possible to do it natively with dataclasses.

Dataclasses 3.10 added the kw_only attribute (similar to attrs). It allows you to specify which fields are keyword_only, thus will be set at the end of the init, not causing an inheritance problem.

Taking directly from Eric Smith's blog post on the subject:

There are two reasons people [were asking for] this feature:

  • When a dataclass has many fields, specifying them by position can become unreadable. It also requires that for backward compatibility, all new fields are added to the end of the dataclass. This isn't always desirable.
  • When a dataclass inherits from another dataclass, and the base class has fields with default values, then all of the fields in the derived class must also have defaults.

What follows is the simplest way to do it with this new argument, but there are multiple ways you can use it to use inheritance with default values in the parent class:

from dataclasses import dataclass

@dataclass(kw_only=True)
class Parent:
    name: str
    age: int
    ugly: bool = False

@dataclass(kw_only=True)
class Child(Parent):
    school: str

ch = Child(name="Kevin", age=17, school="42")
print(ch.ugly)

Take a look at the blogpost linked above for a more thorough explanation of kw_only.

Cheers !

PS: As it is fairly new, note that your IDE might still raise a possible error, but it works at runtime

🌐
Python
docs.python.org › 3 › library › dataclasses.html
dataclasses — Data Classes
@dataclass class C: a: int # 'a' has no default value b: int = 0 # assign a default value for 'b' In this example, both a and b will be included in the added __init__() method, which will be defined as: ... TypeError will be raised if a field without a default value follows a field with a default value. This is true whether this occurs in a single class, or as a result of class inheritance.
🌐
Reddit
reddit.com › r/learnpython › dataclasses with inheritance?
r/learnpython on Reddit: Dataclasses with Inheritance?
April 18, 2023 -

I have a class Animal and Dog which inherits Animal. Why is it that I get an error if I try to give my Dog class a breed field?

TypeError: non-default argument 'breed' follows default argument

This is my code

from dataclasses import dataclass


@dataclass
class Animal:
    species: str
    arms: int
    legs: int


@dataclass
class Dog(Animal):
    breed: str
    species: str = "Dog"
    arms: int = 0
    legs: int = 4


if __name__ == '__main__':
    jake = Dog(breed="Bulldog")
    print(jake)

I did find that if I add a breed field to Animal I wouldn't get the error.

🌐
Medium
medium.com › @aniscampos › python-dataclass-inheritance-finally-686eaf60fbb5
Python dataclass inheritance, finally ! | by Anis Campos | Medium
October 25, 2021 - But truth be told, losing the required aspect of fields was infuriating, but still acceptable when considering the huge work provided by the dataclass, i.e, all the boilerplate removed (immutability, constructor, comparator, hash, to string, etc…) Now not only can we freely inherit and never find ourselves adding default values to untold amount of fields (when you have several layer of inheritance, try adding a default value in the base class and see for yourself…) but we also can forget about the need to order the fields in the class depending on whether they are optional or required.
🌐
GitHub
github.com › microsoft › pyright › issues › 7702
dataclass subclass incorrectly inheriting default fields (false negative) · Issue #7702 · microsoft/pyright
April 14, 2024 - # pyright: strict import dataclasses as dc @dc.dataclass(frozen=True) class Base: foo: int | None = dc.field(default=None) @dc.dataclass(frozen=True) class Sub(Base): foo: int x = Sub() # pyright flags no error here, which is consistent with Python's current runtime behavior, but this is unsound.
Author   kwshi
🌐
Mattdood
mattdood.com › 2023 › 1 › python-dataclass-inheritance-with-default-values-is-wonky-20230124114200
python dataclass inheritance with default values is wonky | Matthew Wimberly
This is particularly true with inheritance, where I noticed that I received a "recursive limit reached" when attempting to return an asdict() representation. To fix this, I used a workaround that returns the dictionary representation using fields to create a key-value pairing. from dataclasses import dataclass, field, fields from typing import Union # Example set of keys to remove before returning to the consumer REMOVE_THESE_KEYS = {'_internal_key_id_one', '_internal_key_id_two'} @dataclass class Example: pass class ExampleChild(Example): pass def get_dict_representation(datarepresentation: Union[Example, ExampleChild]) -> Dict: return dict( (field.name, getattr(datarepresentation, field.name)) for field in fields(datarepresentation) if field.name not in REMOVE_THESE_KEYS )
🌐
Emilearthur
emilearthur.github.io › fastblog › python › oop › data › 2021 › 08 › 18 › DataClass-Inheritance-and-Composition.html
Dataclass - Inheritance and Composition | Emile’s Blog
August 18, 2021 - In the code above, we extended the function in example one by defining a default value for working_hrs attribute. Example Three: Here, things get a bit complicated. We create a new class, EmployeeDB and use field to define the class attribute _employees. We further use __post_init__ to modify the _employees data defined earlier, and finally, we created a method to display all _employees when called. import uuid from dataclasses import dataclass, field from typing import List, Dict def gen_random_id(): return uuid.uuid1().hex @dataclass class Employee: name: str id: str = field(default_factory=
🌐
Real Python
realpython.com › python-data-classes
Data Classes in Python (Guide) – Real Python
March 8, 2024 - In theory, you could now use this function to specify a default value for Deck.cards: ... from dataclasses import dataclass from typing import List @dataclass class Deck: # Will NOT work cards: List[PlayingCard] = make_french_deck() Don’t do this! This introduces one of the most common anti-patterns in Python: using mutable default arguments.
🌐
Python
peps.python.org › pep-0557
PEP 557 – Data Classes | peps.python.org
An example: @dataclass class Base: ... = 15, y: int = 0, z: int = 10): If a field specifies a default_factory, it is called with zero arguments when a default value for the field is needed....
Find elsewhere
🌐
Python
bugs.python.org › issue36077
Issue 36077: Inheritance dataclasses fields and default init statement - Python tracker
This issue tracker has been migrated to GitHub, and is currently read-only. For more information, see the GitHub FAQs in the Python's Developer Guide · This issue has been migrated to GitHub: https://github.com/python/cpython/issues/80258
🌐
GitHub
github.com › cython › cython › issues › 4799
[BUG] Fields are not correctly inherited from parent to child in dataclasses · Issue #4799 · cython/cython
April 12, 2022 - If you place @cython.dataclasses.dataclass on cdef classes in .pxd then fields from parent are added to child but default values are lost and you are forced to fill this value. Case2. You place @cython.dataclasses.dataclass only in .pyx then field is missing from __init__ and is present in object as None ... import cython @cython.dataclasses.dataclass(kw_only=True) @cython.cclass cdef class Document: _id: str = cython.dataclasses.field(default_factory=lambda: str(bson.ObjectId()))
Published   May 19, 2022
Author   Yurzs
🌐
Read the Docs
stackless.readthedocs.io › en › 3.7-slp › library › dataclasses.html
dataclasses — Data Classes — Stackless-Python 3.7.9 documentation
fields may optionally specify a default value, using normal Python syntax: @dataclass class C: a: int # 'a' has no default value b: int = 0 # assign a default value for 'b' In this example, both a and b will be included in the added __init__() method, which will be defined as: ... TypeError will be raised if a field without a default value follows a field with a default value. This is true either when this occurs in a single class, or as a result of class inheritance.
🌐
Stack Overflow
stackoverflow.com › questions › 72623411 › inherited-dataclass-default-value-override-only-works-if-type-hints-match
python - Inherited dataclass default value override only works if type hints match? - Stack Overflow
from dataclasses import dataclass @dataclass class Test: text:str = "Test" @dataclass class Test2(Test): text = "Overwritten" a = Test() b = Test2() print(a,b) Outputs this: Test(text='Test') Test2(text='Test') in Test2, I'm trying to change the default value of 'text' to "overwritten" but this doesn't work.
🌐
Runebook.dev
runebook.dev › en › docs › python › library › dataclasses › inheritance
Inheritance Hacks for Python Dataclasses (Avoiding the TypeError)
This is the cleanest and most recommended solution if you're using Python 3.10 or newer. It forces all fields to be keyword-only arguments in the generated __init__ method. By making all arguments keyword-only, the strict positional rule ("non-default argument follows default argument") no longer applies, completely solving the inheritance problem. from dataclasses import dataclass # Use kw_only=True on the base class (and ideally, all classes in the hierarchy) @dataclass(kw_only=True) class BaseItem: item_id: int category: str = "General" @dataclass(kw_only=True) class SpecificItem(BaseItem): # Now you can mix and match default/non-default fields freely!
🌐
Python.org
discuss.python.org › python help
Dataclasses: subclassing a dataclass without its fields inherited as init-fields - Python Help - Discussions on Python.org
August 12, 2024 - I was wondering if it would be possible to allow subclassing a dataclass without automatically including its fields in Subclass.__init__ (in some sense, hiding the inherited fields). When subclassing the dataclass AB below to create CD, the fields of AB become fields of CD, automatically included ...
🌐
Google Groups
groups.google.com › g › dev-python › c › bYNjBGM0TzI
[Python-Dev] Concerns about method overriding and subclassing with dataclasses
If I make the effort of having a dataclass inherit from a base class, I probably don't want the base class' methods to be silently overriden by machine-generated methods. Of course, that can be worked around by using multiple inheritance, you just need to be careful and add a small amount of class definition boilerplate. I would expect dataclass parameters such as `repr` to be tri-state: * repr=None (the default): only provide a machine-generated implementation if none is already defined (either on a base class or in the dataclass namespace...
🌐
PyPI
pypi.org › project › dataclassy
dataclassy · PyPI
Dynamically create a data class with name name, fields fields, default field values defaults and inheriting from bases. Return a new copy of dataclass with field values replaced as specified in changes.
      » pip install dataclassy
    
Published   Jan 14, 2023
Version   1.0.1
🌐
Studytonight
studytonight.com › post › inheritance-in-python-dataclass
Inheritance in Python Dataclass - Studytonight
June 24, 2023 - Yes, you can override attributes and methods inherited from a dataclass in Python.