<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 21, 2017, 03:37 Ivan Levkivskyi, <<a href="mailto:levkivskyi@gmail.com">levkivskyi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">On 21 December 2017 at 11:22, Terry Reedy <span dir="ltr"><<a href="mailto:tjreedy@udel.edu" target="_blank">tjreedy@udel.edu</a>></span> wrote:<br></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-6523052015813988656gmail-">On 12/21/2017 4:22 AM, Eric V. Smith wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 12/21/2017 1:46 AM, Chris Barker wrote:<br>
</blockquote>
<br>
</span><span class="m_-6523052015813988656gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I suggest that it be clear in the docs, and ideally in the PEP, that the dataclass decorator is using the *annotation" syntax, and that the the only relevant part it uses is that an annotation exists, but the value of the annotation is essentially (completely?) ignored. <br>
</blockquote>
<br>
I think the PEP is very clear about this: "The dataclass decorator examines the class to find fields. A field is defined as any variable identified in __annotations__. That is, a variable that has a type annotation. With two exceptions described below, none of the Data Class machinery examines the type specified in the annotation."<br>
</blockquote>
<br></span>
This seems clear enough. It could come after describing what a dataclass *is*.<span class="m_-6523052015813988656gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I agree the docs should also be clear about this.<br>
</blockquote>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So we should have examples like:<br>
<br>
@dataclass<br>
class C:<br>
a: ... # field with no default<br>
b: ... = 0 # filed with a default value<br>
<br>
Then maybe:<br>
<br>
@dataclass<br>
class C:<br>
a: "the a parameter" # field with no default<br>
b: "another, different parameter" = 0.0 # field with a default<br>
<br>
Then the docs can go to say that if the user wants to specify a type for use with a static type checking pre-processor, they can do it like so:<br>
<br>
@dataclass<br>
class C:<br>
a: int # integer field with no default<br>
b: float = 0.0 # float field with a default<br>
<br>
And the types will be recognized by type checkers such as mypy.<br>
<br>
And I think the non-typed examples should go first in the docs.<br>
</blockquote></blockquote>
<br></span>
Module some bike-shedding, the above seems pretty good to me.<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>For me, the three options for "don't care" have a bit different meaning:</div><div><br></div><div>* typing.Any: this class is supposed to be used with static type checkers, but this field is too dynamic</div><div>* ... (ellipsis): this class may or may not be used with static type checkers, use the inferred type in the latter case<br></div><div>* "field docstring": this class should not be used with static type checkers</div><div><br></div><div>Assuming this, the second option would be the "real" "don't care". If this makes sense,</div><div>then we can go the way proposed in <a href="https://github.com/python/typing/issues/276" target="_blank">https://github.com/python/typing/issues/276</a> and make ellipsis semantics "official" in PEP 484.</div><div>(pending Guido's approval)<br></div></div></div></div></blockquote></div><div><br></div><div>I vote for option 2 as well.</div><div><br></div><div>I think it's worth reminding people that if they don't like the fact dataclasses (ab)use type hints for their succinct syntax that you can always use attrs instead to avoid type hints. Otherwise whichever approach we agree to from Ivan's suggestions will take care of this.</div><div><br></div><div>As for those who feel dataclasses will force them to teach type hints and they simply don't want to, maybe we could help land protocols and then maybe you can use dataclasses as an opportunity to explicitly teach duck typing?</div><div><br></div><div>But I think the key point I want to make is Guido chose dataclasses to support using the type hints syntax specifically over how attrs does things, so I don't see this thread trying to work around that going anywhere at this point since I haven't seen a solid alternative be proposed after all of this debating.</div><div><br></div><div>-brett</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div>--</div><div>Ivan</div><div><br></div><div><br></div></div></div></div>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/brett%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/brett%40python.org</a><br>
</blockquote></div>