On 11/27/2017 7:31 AM, Sebastian Rittau wrote: > On 27.11.2017 13:23, Eric V. Smith wrote: >> I had something like your suggestion half coded up, except I inspected >> the args to __post_init__() and added them to __init__, avoiding the >> API-unfriendly *args and **kwargs. > I understand your concerns with *args and **kwargs. I think we need to > find a solution for that eventually. > >> One other thing about InitVar: it lets you control where the init-only >> parameter goes in the __init__ call. This is especially important with >> default values: > > This is indeed a nice property. I was thinking about that myself and how > to best handle it. One use case that could occur in out codebase is > passing in a "context" argument. By convention, this is always the first > argument to the constructor, so it would be nice if this would also work > for dataclasses. And that's the one thing that you can't do with an alternate classmethod constructor, and is the reason I added InitVar: you can't force a non-field parameter such as a context (or in my example, a database) to be always present when instances are constructed. And also consider the "replace()" module method. InitVars must also be supplied there, whereas with a classmethod constructor, they wouldn't be. This is for the case where a context or database is needed to construct the instance, but isn't stored as a field on the instance. Again, not super-common, but it does happen. My point here is not that InitVar is better than __post_init__ parameter hoisting for this specific need, but that both of them provide something that classmethod constructors do not. I'll add some wording on this to the PEP. Eric.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4