<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>

<br></div>(2) For type annotations, should we adopt (roughly) the mypy syntax or the alternative proposed by Dave Halter? This uses built-in container notations as a shorthand, e.g. {str: int} instead of Dict[str, int]. This also touches on the issue of abstract vs. concrete types (e.g. iterable vs. list).<br>

<br>Regarding (1), I continue to believe that we should eventually reserve annotations for types, to avoid confusing both humans and tools, but I think there's nothing we have to do in 3.5 -- 3.5 must preserve backward compatibility, and we're not proposing to give annotations any new semantics anyway -- the actual changes to CPython are limited to a new stdlib module (typing) and some documentation.<br>

<br></div>Perhaps a thornier issue is how mypy should handle decorators that manipulate the signature or annotations of the function they wrap. But I think the only reasonable answer here can be that mypy must understand what decorators do if it wants to have any chance at type-checking decorated functions. I don't actually know how sophisticated mypy's understanding of decorators is, currently, but I don't think there's anything fundamentally more difficult than all the other things it must understand.<br>

<br></div><div>Moving on to (2), the proposal is elegant enough by itself, and indeed has the advantage of being clear and concise: [T] instead of List[T], {T: U} instead of Dict[T, U], and so on. However, there are a few concerns.<br>

<br>My first concern is that these expressions are only unambiguous in the context of function annotations. I want to promote the use of type aliases, and I think in general a type alias should behave similarly to an ABC. In particular, I think that any object used to represent a type in an annotation should itself be a type object (though you may not be able to instantiate it), and e.g. [int] doesn't satisfy that requirement. Without this, it would be difficult to implement isinstance() and issubclass() for type aliases -- and while we could special-case lists, sets and dicts, using a tuple *already* has a meaning!<br>

<br></div><div>The second concern is that the proposal seems to steer users in the direction of using concrete types. A lot of Python's power stems from concepts like iterable and mapping and their variants (e.g. iterable, container, sequence, mutable sequence). There are justified concerns that users will unnecessarily constrain the argument types more than necessary (e.g. specifying a sequence where any iterable would do), and this proposal lacks the subtlety to express the difference.<br>

<br></div><div>A third (minor) concern reflects issue (1): until we have agreement that annotations should only be used as type annotations, a type checker cannot assume that the presence of annotations means that types should be checked. Using e.g. Iterable[int] is pretty unambiguous (especially when Iterable is imported from typing.py), whereas just [int] is somewhat ambiguous. I call this only a minor issue because it still occurs for simple types like int or str, so if we can live with it for those we could presumably live with [int] and {str: float}.<br>

<br></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. 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.<br>

<br></div><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).<br>

</div><div><div><div><div><div><div><div><div><div><br><div class="gmail_extra">-- <br>--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)
</div></div></div></div></div></div></div></div></div></div></div>