On 27.11.2017 12:01, Sebastian Rittau wrote:
>
>> The major changes from the previous version are:
>>
>> - Add InitVar to specify initialize-only fields.
>
> This is the only feature that does not sit right with me. It looks
> very obscure and "hacky". From what I understand, we are supposed to
> use the field syntax to define constructor arguments. I'd argue that
> the name "initialize-only fields" is a misnomer, which only hides the
> fact that this has nothing to do with fields at all. Couldn't
> dataclassses just pass *args and **kwargs to __post_init__()? Type
> checkers need to be special-cases for InitVar anyway, couldn't they
> instead be special cased to look at __post_init__ argument types?
I am sorry for the double post, but I thought a bit more about why this
does not right with me:
* As written above, InitVars look like fields, but aren't.
* InitVar goes against the established way to pass through arguments,
*args and **kwargs. While type checking those is an unsolved
problem, from what I understand, I don't think we should introduce a
second way just for dataclasses.
* InitVars look like a way to satisfy the type checker without
providing any benefit to the programmer. Even when I'm not
interested in type checking, I have to declare init vars.
* InitVars force me to repeat myself. I have the InitVar declaration
and then I have the repeat myself in the signature of
__post_init__(). This has all the usual problems of repeated code.
I hope I did not misunderstood the purpose of InitVar.
- Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171127/1009adcc/attachment.html>
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