[Python-ideas] Structural type checking for PEP 484
rymg19 at gmail.com
Thu Sep 17 23:19:30 CEST 2015
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): ...
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
>> code in existence).
>You can't just wave a magic wand and to get every programmer to add
>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,
>> 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.
>> 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)
>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
>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
>> -- 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
>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. :)
>Python-ideas mailing list
>Python-ideas at python.org
>Code of Conduct: http://python.org/psf/codeofconduct/
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
More information about the Python-ideas