There's also a variant of (1) that Łukasz Langa would like to see -- use the syntactic position of function annotations but using a custom syntax (e.g. one similar to the pytypedecl syntax) that isn't evaluated at function-definition time. This would have to use "from __future__ import <something>" for backward compatibility. I'm skeptical about this though; it is only slightly more elegant than mypy, and it would open the floodgates of unconstrained language design.

I see the decision has been made. For the curious, the design would be as close as possible to PEP 3107. The biggest wins would be first-class annotations for variables (supported in Mypy as comments) and support for forward-references without the need to fall back to strings.

I’m also not a fan of the square brackets for generics (those brackets mean lookup!) but a BDFL once said that “language evolution is the art of compromise” and one cannot disagree with that.

So there you have it. I am picking the mypy family and I hope we can start focusing on specific improvements to mypy.

Alright! That sounds good. With the syntax mostly out of the way, the next issue to handle is the typing module. dict, MutableMapping, and now Dict… One step too far. We should be able to re-use ABCs for that, e.g. to add support for union types and generics. Lots of decisions ahead (covariance, casting, multiple dispatch, etc.) but we’ll get there.

The typing module as aliases for the updated ABCs sounds like a fair compromise, although I’m worried about the details of that approach (for starters: we need to bundle the new ABCMeta to support union types but having both implementations at runtime feels very wrong). Moreover, with dynamic type registration and duck typing isinstance(), there will be challenges to cover. I’m happy to go and slay that dragon.