[Python-Dev] Second post: PEP 557, Data Classes (original) (raw)

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 postinit() 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