[Python-ideas] Structural type checking for PEP 484

[Ryan Gonzalez]

On September 16, 2015 3:42:20 PM CDT, "Sven R. Kunze" <srkunze at mail.de> wrote:
>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.

def process_integer_coordinate_tuples(integer_tuple_1, integer_tuple_2, is_fast): ...

vs

def process_coords(t1: Tuple[int, int], t2: Tuple[int, int], fast: bool): ...

Java's fatal mistake.

>
>> 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
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Python-ideas mailing list
>Python-ideas at python.org
>https://mail.python.org/mailman/listinfo/python-ideas
>Code of Conduct: http://python.org/psf/codeofconduct/

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.