<div dir="ltr">(subject for this sub-thread updated)<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 21, 2017 at 4:08 PM Chris Barker <<a href="mailto:chris.barker@noaa.gov">chris.barker@noaa.gov</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"><div class="gmail_extra"><div class="gmail_quote">On Thu, Dec 21, 2017 at 3:36 PM, Gregory P. Smith <span dir="ltr"><<a href="mailto:greg@krypto.org" target="_blank">greg@krypto.org</a>></span> wrote:<br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> But we already have ... which does - so I'd suggest that for people who are averse to importing anything from typing and using the also quite readable Any. (ie: document this as the expected practice with both having the same meaning)</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I don't think they do, actually - I haven't been following the typing discussions, but someone in this thread said that ... means "use the type of teh default" or something like that.</div></div></div></div></blockquote><div><br></div><div>indeed, they may not. though if that is the definition is it reasonable to say that type analyzers recognize the potential recursive meaning when the _default_ is ... and treat that as Any?</div><div><br></div><div>another option that crossed my mind was "a: 10" without using =. but that really abuses __attributes__ by sticking the default value in there which the @dataclass decorator would presumably immediately need to undo and fix up before returning the class. but I don't find assigning a value without an = sign to be pythonic so please lets not do that! :)</div><div><br></div><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> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>While I consider the annotation to be a good feature of data classes, it seems worth documenting that people not running a type analyzer should avoid declaring a type.</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>+1 !</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> A worse thing than no-type being specified is a wrong type being specified. That appearing in a library will break people who need their code to pass the analyzer and pytype, mypy, et. al. could be forced to implement a typeshed.pypi of sorts containing blacklists of known bad annotations in public libraries and/or actually correct type specification overrides for them.</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>and the wrong type could be very common -- folks using "int", when float would do just fine, or "list" when any iterable would do, the list goes on and on. Typing is actually pretty complex in Python -- it's hard to get right, and if you aren't actually running a type checker, you'd never know.</div></div></div></div></blockquote><div><br></div><div>Yeah, that is true. int vs float vs Number, etc. It suggests means we shouldn't worry about this problem at all for the pep 557 dataclasses implementation. Type analyzers by that definition are going to need to deal with incorrect annotations in data classes as a result no matter what so they'll deal with that regardless of how we say dataclasses should work.</div><div><br></div><div>-gps</div><div> </div><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><br></div><div>One challenge here is that annotations, per se, aren't only for typing. Bu tit would be nice if a type checker could see whatever "non-type" is recommended for dataclasses as "type not specified". Does an ellipses spell that? or None? or anything that doesn't have to be imported from typing :-)</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>As for problems with order, if we were to accept</div><div><br></div><div>@dataclass</div><div>class Spam:</div><div> beans = True</div><div> ham: bool</div><div><br></div><div>style instead, would it be objectionable to require keyword arguments only for dataclass __init__ methods? That'd get rid of the need to care about order. </div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>wouldn't that make the "ham: bool" legal -- i.e. no default?</div><div><br></div><div>-CHB</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_extra"><br></div>-- <br><div class="m_-5606420344398705742gmail_signature" data-smartmail="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R <a href="tel:(206)%20526-6959" value="+12065266959" target="_blank">(206) 526-6959</a> voice<br><a href="https://maps.google.com/?q=7600+Sand+Point+Way+NE&entry=gmail&source=g">7600 Sand Point Way NE</a> <a href="tel:(206)%20526-6329" value="+12065266329" target="_blank">(206) 526-6329</a> fax<br>Seattle, WA 98115 <a href="tel:(206)%20526-6317" value="+12065266317" target="_blank">(206) 526-6317</a> main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div></blockquote></div></div>