syntax difference

Ian Kelly ian.g.kelly at gmail.com
Mon Jun 18 14:01:20 EDT 2018


On Mon, Jun 18, 2018 at 11:39 AM Jim Lee <jlee54 at 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.



More information about the Python-list mailing list