[Python-ideas] Structural type checking for PEP 484
Sven R. Kunze
srkunze at mail.de
Thu Sep 10 18:42:46 CEST 2015
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>
More information about the Python-ideas
mailing list