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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
