[Python-Dev] Second post: PEP 557, Data Classes

[Eric V. Smith]

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.