Thanks for the link. I developed the annotation+decorator-based type checker in https://github.com/kislyuk/ensure https://github.com/kislyuk/ensure before I saw

Thanks for the link. I developed the annotation+decorator-based type checker in https://github.com/kislyuk/ensure https://github.com/kislyuk/ensure before I saw typecheck-decorator (which looks like it has some cool features). One thing I'm proud of with ensure's @ensure_annotations decorator is that we actually went through a few rounds of optimization and are fairly confident in the decorator's runtime performance. Optional type checking as a first-class citizen is a great tool to have, and it's good to see the syntax standardized. But as alluded to in the Reddit thread, there are serious issues with this PEP. The use of comments and the lack of runtime type checking from the start not only limits the potential of this particular PEP, but undermines future efforts to bring that functionality in. IMO it would have been better to put in the work and properly integrate type checking decorations into the interpreter and the grammar. The tack-on comments at the end of the line are especially un-Pythonic and jarring. Edit: Just saw the string literal based forward references. Ugh. Another problem in the making.