On Wed, Sep 9, 2015 at 3:02 PM, Sven R. Kunze <srkunze@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