Back when dataclassy used __new__ to set class fields (pre-v0.7), __init__ was left free for the user to use for post-initialisation logic. This worked well, but since v0.7, dataclassy has used __init__ for its own purposes. To retain compatibility, an __init__ method defined on a class where init=True is aliased to __post_init__. This is rather confusing and raises a lot of uncertain edge cases:
what happens if both __init__ and __post_init__ are defined?
what happens if one is defined or redefined later in the class hierarchy?
and likely many more (e.g. #43)
In addition, strictly speaking these theoretical subtle differences in behaviour mean that test cases should test the same scenarios for both method names.
Finally, judging by the code examples in the issues here, no one really uses it. Therefore I now think this compatibility should be removed. I expect this to be the last breaking change before a stable release (and there haven't been many!).
My plan is to:
Raise a DeprecationWarning in the next release (v0.9)
Remove the feature the next major release after that (v0.10)
Set __init__ equal to __post_init__ if the former is not generated (init=False or no fields) and the latter is defined. This is the only reason not to use __post_init__ currently, and fixes another bug in dataclasses.
Back when dataclassy used
__new__
to set class fields (pre-v0.7),__init__
was left free for the user to use for post-initialisation logic. This worked well, but since v0.7, dataclassy has used__init__
for its own purposes. To retain compatibility, an__init__
method defined on a class whereinit=True
is aliased to__post_init__
. This is rather confusing and raises a lot of uncertain edge cases:__init__
and__post_init__
are defined?In addition, strictly speaking these theoretical subtle differences in behaviour mean that test cases should test the same scenarios for both method names.
Finally, judging by the code examples in the issues here, no one really uses it. Therefore I now think this compatibility should be removed. I expect this to be the last breaking change before a stable release (and there haven't been many!).
My plan is to:
DeprecationWarning
in the next release (v0.9)__init__
equal to__post_init__
if the former is not generated (init=False
or no fields) and the latter is defined. This is the only reason not to use__post_init__
currently, and fixes another bug in dataclasses.