[Python-ideas] Structural type checking for PEP 484

[Jukka Lehtosalo]

On Wed, Sep 9, 2015 at 3:02 PM, Sven R. Kunze <srkunze at mail.de> wrote:

> Not specifically about this proposal but about the effort put into Python
> typehinting in general currently:
>
>
> What are the supposed benefits?
>

This has been discussed almost to the death before, but there are some of
main the benefits as I see them:

- Code becomes more readable. This is especially true for code that doesn't
have very detailed docstrings. This may go against the intuition of some
people, but my experience strongly suggests this, and many others who've
used optional typing have shared the sentiment. It probably takes a couple
of days before you get used to the type annotations, after which they
likely won't distract you any more but will actually improve code
understanding by providing important contextual information that is often
difficult to infer otherwise.
- Tools can automatically find most (simple) bugs of certain common kinds
in statically typed code. A lot of production code has way below 100% test
coverage, so this can save many manual testing iterations and help avoid
breaking stuff in production due to stupid mistakes (that humans are bad at
spotting).
- Refactoring becomes way less scary, especially if you don't have close to
100% test coverage. A type checker can find many mistakes that are commonly
introduced when refactoring code.

You'll get the biggest benefits if you are working on a large code base
mostly written by other people with limited test coverage and little
comments or documentation. You get extra credit if your tests are slow to
run and flaky, as this slows down your iteration speed, whereas type
checking can be quick (with the right tools, which might not exist as of
now ;-). If you have a small (say, less than 10k lines) code base you've
mostly written yourself and have meticuously documented everything and have
95% test coverage and your full test suite runs in 10 seconds, you'll
probably get less out of it. Context matters.


>
> I somewhere read that right now tools are able to infer 60% of the types.
> That seems pretty good to me and a lot of effort on your side to make some
> additional 20?/30? %. Don't get me wrong, I like the theoretical and
> abstract discussions around this topic but I feel this type of feature way
> out of the practical realm.
>

Such a tool can't infer 40% of the types. This probably includes most of
the tricky parts of the program that I'd actually like to statically check.
A type checker that uses annotations might understand 95% of the types,
i.e. it would miss 5% of the types. This seems like a reasonable figure for
code that has been written with some thought about type checkability. I
consider that difference pretty significant. I wouldn't want to increase
the fraction of unchecked parts of my annotated code by a factor of 8, and
I want to have control over which parts can be type checked.

Jukka


>
> I don't see the effort for adding type hints AND the effort for further
> parsing (by human eyes) justified by partially better IDE support and 1
> single additional test within test suites of about 10,000s of tests.
>
> Especially, when considering that correct types don't prove functionality
> in any case. But tested functionality in some way proves correct typing.
>
> Just my two cents since I felt I had to say this and maybe I am missing
> something. :)
>
> Best,
> Sven
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150909/8dd5a97f/attachment-0001.html>