On 11.09.2015 08:24, Jukka Lehtosalo wrote:
On Thu, Sep 10, 2015 at 9:42 AM, Sven R. Kunze <srkunze@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