Dexter Hill wrote:
I don't mind that solution although my concern is whether it would be confusing to have `init` have two different purposes depending on the argument. And, if `__post_init__` was overrided, which I would say it commonly is, that would mean the user would have to manually do the conversion, as well as remembering to add an extra argument for the conversion function (assuming I'm understanding what you're saying). If no type was provided to `init` but a conversion function was, it would be a case of getting the type from the function signature, right?
The reason I am saying to use the 'init' argument is that it seems to me to be a variation on what that argument already does. It controls whether the argument is passed to the generated `__init__` method. Passing a type as the value for 'init' would now behave like sort of a cross between `init=False` and `InitVar`. The field would still be created (unlike `InitVar`) but would not be automatically assigned the value passed as its corresponding argument, leaving that responsibility to `__post_init__`. Like with `InitVar`, the argument would be passed to `__post_init__` since it was not processed by `__init__`. The type annotation would continue to specify the type of the field, and the type passed to the 'init' argument would specify the type of its constructor argument.