Could the type hint for the __init__ parameter be inferred from the (proposed) init_fn's own parameter type hint itself?
On Tue, 2022-06-28 at 16:39 +0000, Steve Jorgensen wrote: > 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/
_______________________________________________ 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/Z7BFI6Q57SGMYBT4SFLC5QHNNYTU7FCV/ Code of Conduct: http://python.org/psf/codeofconduct/
