On 10.09.2015 06:12, Jukka Lehtosalo wrote:
This has been discussed almost to the death before,

I am sorry. :)

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.

If I have code without docstrings, I better write docstrings then. ;)

I mean when I am really going to touch that file to improve documentation (which annotations are a piece of), I am going to add more information for the reader of my API and that mostly will be describing the behavior of the API.

If my variables have crappy names, so I need to add type hints to them, well, then, I rather fix them first.

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.

If I had large untested and undocumented code base (well I actually have), then static type checking would be ONE tool to find out issues.

Once found out, I write tests as hell. Tests, tests, tests. I would not add type annotations. I need tested functionality not proper typing.

You get extra credit if your tests are slow to run and flaky,

We are problem solvers. So, I would tell my team: "make them faster and more reliable".

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.

Granted. But you still don't know if your code runs correctly. You are better off with tests. And I agree type checking is 1 test to perform (out of 10K).

But:


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.

I didn't see you respond to that. But you probably know that. :)

Thanks for responding anyway. It is helpful to see your intentions, though I don't agree with it 100%.

Moreover, I think it is about time to talk about this. If it were not you, somebody else would finally have added type hints to Python. Keep up the good work. +1

Best,
Sven