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. _______________________________________________ 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/BCN2BUZSM6KH5VSTKHYWI3CB5UVDDNUH/ Code of Conduct: http://python.org/psf/codeofconduct/
