Steve Jorgensen wrote:
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.? That's definitely an improvement that could be made, although I think it would require a large amount of changes. I don't know if you had syntax in mind for it, or an easy way to represent it, but at least from what I understand you would probably a whole new function like `field`, but that handles just that functionality, otherwise it would add a lot of arguments to `field`.
Steve Jorgensen wrote:
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. So the use case would be either this:
@dataclass
class Foo:
x: InitFn[str] = field(converter=chr)
where the field `x` has the type string, and the type for the `x` parameter in `__init__` would be derrived from `chr`, or optionally: ```py @dataclass class Foo: x: InitFn[str, int] = field(converter=chr) ``` where you can provide a second type argument that specifies the type parameter for `__init__`?