On Mon, Jun 18, 2018 at 11:39 AM Jim Lee <jle...@gmail.com> wrote: > On 06/18/2018 07:03 AM, Steven D'Aprano wrote: > > As a human programmer, you surely perform your own ad hoc type checking > > when you write and debug code. > Of course. And, I use linting tools and other forms of static type > checking. What I don't like is adding the *syntax* for static type > checking to the (dynamically typed) language proper, particularly when > the implementations of said language do nothing but ignore it. > > The syntax should be defined inside comments, by the tools that actually > need to use them. Let the tools do what they were designed to do. Let > the language do what it was designed to do.
If you want to use a type checking tool that uses type comments, then by all means do so. The existence of annotation syntax in no way prevents that. When PEP 3107 was written, it was anticipated that annotations would find more uses than just type hinting. Some of those proposed ideas (e.g. database query mapping) depend on the annotation being readable at run-time, for which a comment would be wholly inadequate. In practice, I don't think that has really been borne out. Still, the intention was to make the language more flexible, not just to cram in type hinting, and I don't think that was necessarily a bad idea. PEP 484 was created out of the observation that the community of static type analysis tools that has grown out of PEP 3107 would benefit from a common dialect of types. All it does is provide that. Neither of these are forcing you to use a type checker that requires annotations for type hints rather than comments, if that's what you prefer. The annotation-based checker is probably a fair bit easier to build from the maintainer's standpoint, though, since it can rely on existing parsing tools and the typing module. -- https://mail.python.org/mailman/listinfo/python-list
