Home Original page

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

Eric V. Smith eric at trueblade.com
Mon Nov 27 07:42:07 EST 2017 
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.
More information about the Python-Dev mailing list