biqqles/dataclassy

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.