Sure but nobody ever writes tests that are as comprehensive at checking the basic types of stuff as simply adding static type hints (which is very easy if you start with them).
How many times have you seen a NoneType error or a KeyError? It's probably the most common class of bugs in Python and there's an easy way to eliminate it. And as a nice side effect your code is way easier to understand, navigate and edit.
I still sometimes have to give up and use Any in Python, partly because half the Python community haven't realised their mistake yet. But that's fine. It's still way better.
I took over maintenance of a big untestable program in Python once (a build system). None of it was designed for testing and every change I made would trigger some bug. The cost of running the whole program was about an hour of building so every tiny problem was incredibly frustrating.
I thought adding types might help to remove the most trivial mistakes and help me get it into shape faster. All I can say is that it didn't. The easiest mistakes to make were not the kind of things that triggered typing issues.
When I bit the bullet and found some things that could be made testable - only then did the burden start to fall and to sort of exponentially disappear. Each test, crappy and incomplete as it might have been, made it easier to refactor so that the next test could be added. I went from system tests inwards towards unit test because this, again, had the biggest benefit/cost.
So my thesis is that big general tests do more for you at the start and honing in towards more detailed ones returns less and less value. In this model I see types as being fairly detailed level tests so they can happen later on. This is a facetious, throwaway idea that just occurred to me so don't take it too seriously.
Comments
Sure but nobody ever writes tests that are as comprehensive at checking the basic types of stuff as simply adding static type hints (which is very easy if you start with them).
How many times have you seen a NoneType error or a KeyError? It's probably the most common class of bugs in Python and there's an easy way to eliminate it. And as a nice side effect your code is way easier to understand, navigate and edit.
I still sometimes have to give up and use Any in Python, partly because half the Python community haven't realised their mistake yet. But that's fine. It's still way better.
I took over maintenance of a big untestable program in Python once (a build system). None of it was designed for testing and every change I made would trigger some bug. The cost of running the whole program was about an hour of building so every tiny problem was incredibly frustrating.
I thought adding types might help to remove the most trivial mistakes and help me get it into shape faster. All I can say is that it didn't. The easiest mistakes to make were not the kind of things that triggered typing issues.
When I bit the bullet and found some things that could be made testable - only then did the burden start to fall and to sort of exponentially disappear. Each test, crappy and incomplete as it might have been, made it easier to refactor so that the next test could be added. I went from system tests inwards towards unit test because this, again, had the biggest benefit/cost.
So my thesis is that big general tests do more for you at the start and honing in towards more detailed ones returns less and less value. In this model I see types as being fairly detailed level tests so they can happen later on. This is a facetious, throwaway idea that just occurred to me so don't take it too seriously.