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:
```py
@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__`?
_______________________________________________
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/72ARTBIVL3JVWYHSQHHS5OMVQRTM4L4W/
Code of Conduct: http://python.org/psf/codeofconduct/
