[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