Removing support for post-initialisation logic in `__init__`
Closed this issue · 0 comments
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.