<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 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="gmail-">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="gmail-"><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="gmail-"><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>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">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><br></div><div>--</div><div>Ivan</div><div><br></div><div><br></div></div></div></div>