(my first post seems to have been accepted by google groups but rejected by the mailing list. The first repost attempt was completely destructured by outlook > Reposting a 2d time… VERY sorry for the inconvenience, I’m not familiar with google groups) Hello there I recently found out that while I was developing autoclass https://smarie.github.io/python-autoclass/ in complete, naïve ignorance of the python evolution process, there was a PEP (557, here https://www.python.org/dev/peps/pep-0557/) growing, being proposed by Eric V. Smith; and now accepted since december. While this PEP is a GREAT step forward developer-friendly classes in python, I do not feel that it covers all of the use cases I wanted to cover with autoclass. I discussed with Eric about the particular one below and he suggested to post it here: In the case users want to benefit from the code generation while keeping custom __init__ methods the current proposal leads to double declaration as shown in the pep. https://www.python.org/dev/peps/pep-0557/#custom-init-method The choice I made with autoclass is opposite/complementary: rather than using class descriptor to define fields, the developer includes all of them in the __init__ method signature, and an optional include/exclude parameter allows him/her to further customize the list if need be. See here https://smarie.github.io/python-autoclass/#basic. I think that both ways to declare fields actually make sense, depending on the use case. Compact pure-data classes will be more compact and readable with fields defined as class descriptors. Hybrid data+logic classes with custom constructors will be more compact if the fields used in the custom constructor signature are not defined twice (also in a descriptor). Supporting both ways to declare the fields, possibly both styles in the same class definition (but does it make sense? not sure), would avoid duplication when users want custom constructors. The example in the pep https://www.python.org/dev/peps/pep-0557/#custom-init-method would become: @dataclass() class ArgHolder: def __init__(self, *args: Any, **kwargs: Any): pass Does that make sense ? Kind regards Sylvain