[Python-ideas] Structural type checking for PEP 484

[Sven R. Kunze]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150910/940becdb/attachment.html>