Dexter Hill wrote:
Ah right I see what you mean. In my example I avoided the use of `__init__` and specifically `__post_init__` as (and it's probably a fairly uncommon use case), in my actual project, `__post_init__` is defined on a base class, and inherited by all other classes, and I wanted to avoid overriding `__post_init__` (and super-ing). The idea was to have the conversion generated by the dataclass, within the `__init__` no function were required to be defined (similarly to how converters work in attrs). With your suggestion, what do you think about having something similar to `InitVar` so it's more in line with how `__post_init__` currently works? For example, like one of my other suggestions, having a type called `InitFn` which takes two types: the type for `__init__` and the type of the actual field.
Now I see why you wanted to avoid using __post_init__. I had been thinking to try to use __post_init_ instead of adding more ways to initialize, but your reasoning makes a lot of sense. Would we want something more general that could deal with cases where the input does not have a 1-to-1 mapping to the field that differ only, perhaps, in type hint? What if we want 1 argument to initializes 2 properties or vice verse, etc.? In any case, having a new `InitFn` is worth digging into, I don't think it needs to have 2 arguments for type since the type annotation already covers 1 of those cases. I think it makes the most sense for the type annotation to apply to the property and the type of the argument to be provided either through an optional argument to `InitFn` or maybe that can be derived from the signature of the function that `InitFn` refers to.