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. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4DUTNRIRLJKOY3CDRGIU6TZ4NV2RWP5Q/ Code of Conduct: http://python.org/psf/codeofconduct/
