[Python-ideas] Typecheckers: there can be only one

[Nick Coghlan]

On 8 September 2016 at 19:46, Hugh Fisher <hugo.fisher at gmail.com> wrote:
> On Thu, Sep 8, 2016 at 8:00 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>>
>>> Type annotations are code, not tests.
>>
>> Not in Python they aren't.
>
> The interpreter certainly thinks they're code rather than comments or
> docstrings, even before PEP 526. I type this into my Python 3.4
> interpreter:
>
>>>> def foo(x:itn):
>>>> ... return x
>
> and the interpreter raises a NameError because 'itn' is not defined.
>
> Annotations look like code, they're mixed in with names and operators
> and literals and keywords, and all the standard syntax and semantic
> checks are applied.

This is why I quite like the phrase "type assertions", particularly
for the variable annotation form - as with assert statements,
annotations are tests that you can write inline with your code rather
than necessarily putting them in a different file.

That doesn't make them not tests - it just makes them inline
self-tests instead of external ones.

The fact that assertions are checked by default (but can be turned
off), while annotations are ignored by default (but can be checked
with the appropriate optional tooling) has more to do with the
relative maturity of the typecheckers than it does anything else - at
this point in history, you still need to be on the lookout for bugs in
the typecheckers themselves, rather than assuming that because a
typechecker complained, there must be something wrong with the code.

Folks with the kinds of problems that typecheckers solve are likely to
be prepared to put up with the inconvenience of also dealing with bugs
in them. By contrast, folks that just want to run some Python code
that they already know works well enough for their purposes will want
Python to keep working the same way it always has. (Hence why all of
the typechecker developers chiming into these discussions point out
that they always err on the side of *not* complaining about *correct*
code, even if that increases their chances of missing some situations
where the code is actually wrong)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia