<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 22, 2017 at 10:10 AM, Stephan Hoyer <span dir="ltr"><<a href="mailto:shoyer@gmail.com" target="_blank">shoyer@gmail.com</a>></span> wrote:<br><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 Thu, Dec 21, 2017 at 6:39 AM Ivan Levkivskyi <<a href="mailto:levkivskyi@gmail.com" target="_blank">levkivskyi@gmail.com</a>> wrote:<br></span><div class="gmail_quote"><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"><div><div class="gmail_extra"><div class="gmail_quote"><div></div></div></div></div></blockquote></span></div></blockquote><div>Â </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><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"><div><div class="gmail_extra"><div class="gmail_quote"><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></div></div></div></div></blockquote></span></div></blockquote><div>Â </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><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"><div><div class="gmail_extra"><div class="gmail_quote"><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/<wbr>typing/issues/276</a> and make ellipsis semantics "official" in PEP 484.</div><div>(pending Guido's approval)</div></div></div></div></blockquote><div dir="auto"><br></div></span><div dir="auto">I am a little nervous about using "..." for inferred types, because it could potentially cause confusion with other uses of ellipsis in typing.</div></div></blockquote><div><br></div><div>Isn't that what "make ellipsis semantics "official"" means -- i.e. making it clear how they are used in typing?</div><div><br></div><div>The core problem is that generic annotations are used in dataclasses without the "type hints" use-case. But:</div><div><br></div><div>1) Python is moving to make (PEP 484) type hints be THE recommended usage for annotations</div><div><br></div><div>2) We want the annotations in dataclasses to be "proper" PEP 484 type hints if they are there.</div><div><br></div><div>The challenge is:</div><div><br></div><div>- Annotations require a value.</div><div>- Any value used might be interpreted by a static type checker.</div><div><br></div><div>So we need a way to spell "no type specified" that will not be mis-interpreted by type checkers, and is in the built in namespace, and will seem natural to users with no knowledge or interest in static typing.</div><div><br></div><div>The ellipses is tempting, because it's a literal that doesn't have any other obvious meaning in this context. Bu tif it has an incompatible meaning in PEP 484, then we're stuck.</div><div><br></div><div>Is there another Obscure literal that would work?</div><div><br></div><div>Â - I assume None means "the None type" to type checkers, yes?<br></div><div><div><br></div><div>Â - empty string is one option -- or more to the point, any string -- so then it could be used as docs as well.</div></div><div><br></div><div><div>- Is there another Obscure literal that would work? (or not so obscure one that doesn't have another meaning to type checkers)</div></div><div><br></div><div>Would it be crazy to bring typing.Any into the builtin namespace?</div><div><br></div><div>@dataclass:</div><div>Â Â a: Any</div><div>Â Â b: Any = 34</div><div>Â Â c: int = 0</div><div><br></div><div>That reads pretty well to me....</div><div><br></div><div>And having Any available in the built in namespace may help in other cases where type hints are getting introduced into code that isn't really being properly type checked.</div><div><br></div><div>I don't LOVE it -- to me, Any means "any type will do", or "I don't care what type this is" and what we really want is "no type specified" -- i.e. the same thing as plain old Python code without type hints. But practically speaking, it has the same effect, yes?</div><div><br></div><div>-CHB</div><div><br></div><div><br></div></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R Â Â Â Â Â Â (206) 526-6959Â Â voice<br>7600 Sand Point Way NE Â Â (206) 526-6329Â Â fax<br>Seattle, WA Â 98115 Â Â Â Â (206) 526-6317Â Â main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>