<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Aug 16, 2014, at 10:03 PM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br><div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div><div><div><div>I'd like to summarize the main issues that have come up. As an experiment, I'm not changing the subject, but I am still not quoting anything in particular. Only two issues (or issue clusters) really seem contentious:<br>
<br></div>(1) Should the function annotation syntax (eventually) be reserved for type annotations in a standard syntax? Or can multiple different uses of annotations coexist? And if they can, how should a specific use be indicated? (Also, some questions about compile-time vs. run-time use.)<br></div></div></div></div></blockquote><div><br></div><div>Consider what Stefan Behnel is proposing: using function annotations for types by default, but in the presence of a dictionary, search for type in the 'type' key. This is very nice, provides a way to be concise if possible, and generic, if needed.</div><div><br></div><div>My suggestion: we should support that.</div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div><div>All in all I prefer the mypy syntax, despite being somewhat more verbose and requiring an import, with one caveat: I agree that it would be nicer if the mypy abstract collection types were the same objects as the ABCs exported by collections.abc.</div></div></div></blockquote><div><br></div><div>Good :) If the functionality will be implemented in the ABCs, what is the purpose of the typing module?</div><div><br></div><div>My suggestion: if the functionality will be implemented in the ABCs, there's no need to introduce the "typing" module. We can back-port the new ABCs, for sure, but for Python 3.5 `collections` is enough (already has aliases to collections.abc0.</div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div><div>I'm not quite sure whether we should also change the concrete collection types from List, Dict, Set, Tuple to list, dict, set, tuple; the concrete types are so ubiquitous that I worry that there may be working code out there that somehow relies on the type objects themselves not being subscriptable.</div></div></div></blockquote><div><br></div><div>While unlikely, such code can exist in the wild. That being said, I think builtins should support the one-obvious-way-to-do-it syntax for generics, if only for uniformity. Please note that there also can be code in the future that relies on type objects not to support binary-or. We will still need to add this, though, a type union of (int | str) or (str | None) will be a common thing.</div><div><br></div><div>My suggestion: add __getitem__ and __or__/__ror__ to both builtins and ABCs.</div><div><br></div><div>Steven D'Aprano touches on an interesting point that list[int] will be tempting for users because Iterable[int] is both longer and requires an import. We could extend PEP 8 to talk about typing and how people should think about introducing hints, but I think Steven is generally right: list[int] will sadly win.</div><div><br></div><div>The real reason that we'll see list[T] everywhere is that Iterable[str] == str and Sequence[str] == str. Whoever will try and fail to use those abstract types to specify a collection of strings, but *not* a single string, will migrate to using concrete data types. And that's such a common use case!</div><div><br></div><div>AFAIK, there is no good workaround at the moment. The solution for that, which we sadly can't implement, would be to make strings non-iterable. </div><div><br></div><div>My suggestion: two new ABCs, let me temporarily call them StrictIterable and StrictSequence. Those would return False for issubclass(str, ...). </div><div>My other suggestion: deprecate iterating over strings (and possibly bytes, too?). I'm not saying "remove", but just officially say "this was a bad idea, don't use it".</div><div><br></div><div><br></div><blockquote type="cite"><div dir="ltr"><div>A mostly unrelated issue: there are two different uses of tuples, and we need a notation for both. One is a tuple of fixed length with heterogeneous, specific types for the elements; for example Tuple[int, float]. But I think we also need a way to indicate that a function expects (or returns) a variable-length tuple with a homogeneous element type. Perhaps we should call this type frozenlist, analogous to frozenset (and it seems there's a proposal for frozendict making the rounds as well).</div></div></blockquote><div><br></div><div>On one hand, not being able to represent variable-length homogeneous tuples in the type hints will be a strong signal that this usage of tuples is disputable. On the other hand, we might *need* to support this to be compatible with existing framework code in the wild. frozenlists would be a nice, explicit solution for that but sadly they'd be a new collection, so no today's code returning/accepting var-length tuples would use that.</div><div><br></div><div>My suggestion: tuple[int, ...]</div><div>For uniformity, we would also accept this form for other iterables, I suppose.</div></div><br><div apple-content-edited="true">
<div style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">-- <br>Best regards,<br>Łukasz Langa<br><br>WWW: <a href="http://lukasz.langa.pl/">http://lukasz.langa.pl/</a><br>Twitter: @llanga<br>IRC: ambv on #python-dev</div>
</div>
<br></body></html>