[Python-ideas] Structural type checking for PEP 484

[Sven R. Kunze]

On 11.09.2015 08:24, Jukka Lehtosalo wrote:
> On Thu, Sep 10, 2015 at 9:42 AM, Sven R. Kunze <srkunze at mail.de 
> <mailto:srkunze at mail.de>> wrote:
>
>     If my variables have crappy names, so I need to add type hints to
>     them, well, then, I rather fix them first.
>
>
> Even good variable names can leave the type ambiguous.

Try harder then.

> And besides, if you assume that all code is perfect or can be made 
> perfect I think that you've already lost the discussion. Reality 
> disagrees with you. ;-)

Not sure where I said this.

> You can't just wave a magic wand and to get every programmer to 
> document their code and write unit tests. However, we know quite well 
> that programmers are perfectly capable of writing type annotations, 
> and tools can even enforce that they are present (witness all the Java 
> code in existence).

You can't just wave a magic wand and to get every programmer to add type 
annotations to their code. However, we know quite well that programmers 
are perfectly capable of writing unit tests, and tools can even enforce 
that they are present (witness coverage tools and hooks in SCM systems 
preventing it from dropping).

[ Interesting, that it was that easy to exchange the parts you've given 
me ;) ]

Btw. have you heard of code review?

> Tools can't verify that you have good variable names or useful 
> docstrings, and people are too inconsistent or lazy to be relied on.

Same can be said for type annotations.

> In a cost/benefit analysis it may be optimal to spent half the 
> available time on annotating parts of the code base to get some (but 
> necessarily limited) static checking coverage and spend the remaining 
> half on writing tests for selected parts of the code base, for 
> example. It's not all or nothing.

I would like to peer-review that cost/benefit analysis you've made to 
see whether your numbers are sane.

>
>>     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".
>
>
> But you'd probably also ask them to implement new features (or *your* 
> manager might be unhappy), and they have to find the right balance, as 
> they only have 40 hours a week (or maybe 80 hours if you work at an 
> early-stage startup :-). Having more tools gives you more options for 
> spending your time efficiently.

Yes, I am going to tell him: "Hey, it doesn't work but we got all/most 
of the types right."

>
>     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).
>
>
> Actually a type checker can verify multiple properties of a typical 
> line of code. So for 10k lines of code, complete type checking 
> coverage would give you the equivalent of maybe 30,000 (simple) tests. 
> :-P

I think you should be more specific on this.

Using hypothesis, e.g., you can easily increase the number of simple 
tests as well.

What I can tell is that most of the time, a variable carries the same 
type. It is really convenient that it doesn't have to but most of the 
time it does. Thus, one test run can probably reveal a dangerous type 
mistake. I've seen code where that is not the case indeed and one 
variable is either re-used or accidentally have different types. But, 
well, you better stay away from it anyway because most of the time it's 
very old code.

Moreover, in order to add *reasonable* type annotations you would 
probably invest equal amount of time that you would invest to write some 
tests for it. The majority of time is about *understanding* the code. 
And there, better variable names help a lot.

> It's often not cost effective to have good test coverage (and even 
> 100% line coverage doesn't give you full coverage of all 
> interactions). Testing can't prove that your code doesn't have defects 
> -- it just proves that for a tiny subset of possible inputs you code 
> works as expected. A type checker may be able to prove that for *all* 
> possible inputs your code doesn't do certain bad things, but it can't 
> prove that it does the good things. Neither subsumes the other, and 
> both of these are approaches are useful and complementary (but 
> incomplete).

I fully agree on this. Yet I don't need type annotations. ;) A simple 
test running a typechecker working at 40%-60% (depending on whom you 
ask) efficiency suffices at least for me.

I would love to see better typecheckers rather than cluttering our code 
with some questionable annotations; btw. of which I don't know of are 
necessary at all.

Don't be fooled by the possibility of dynamic typing in Python. Just 
because it's possible doesn't necessarily mean it's the usual thing.

> I think that there was a good talk basically about this at PyCon this 
> year, by the way, but I can't remember the title.

It'll be great to have it. :)

Best,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150916/f41a794f/attachment.html>