[Python-ideas] What should a good typechecker do?

Guido van Rossum guido at python.org
Sat Sep 3 11:51:41 EDT 2016


On Sat, Sep 3, 2016 at 8:28 AM, Stephen J. Turnbull
<turnbull.stephen.fw at u.tsukuba.ac.jp> wrote:
> Guido van Rossum writes:
>
>  > But that's not what type comments mean! They don't annotate the
>  > expression. They annotate the variable.
>
> In PEP 484.  But syntactically, AFAICS in an initialization that's a
> distinction without a difference.  It would be perfectly possible to
> write a checker that allows
>
>     if cond:
>         x: str = "a string, what else?"
>     else:
>         x: int = 1
>
> and infers the union, and even infers the types from the expressions
> in
>
>     if cond:
>         x = "a string, what else?"
>     else:
>         x = 1
>
> Once you have that, then the only things that are really being typed
> are the initializer expressions.
>
> I don't understand why some people seem to think that is a *good*
> typechecker (if that's it's normal mode of operation).  But as a tool
> to identify the types that untyped (or ambiguously-typed) code
> actually uses, review them, and help produce a precisely typed
> version, it seems perfectly plausible to me.

That's is why we're not restricting this syntactically. I've seen a
fair amount of untyped code that reuses the same variable name (in the
same scope, often in unit tests), but usually it was serially, e.g.

  target = 42
  assert fooi(target) == '42'
  target = 3.14
  assert foof(target) == '3.14'
  target = 'x'
  assert foos(target) == "'x'"

-- 
--Guido van Rossum (python.org/~guido)


More information about the Python-ideas mailing list