Comment by tpoacher | Hacker News Reader

Comment by tpoacher | Hacker News Reader

On one hand, this "feels" useful ... on the other hand, I can't shake that unnerving feeling that this kind of exhaustiveness check should belong in tests instead.

If the issue is to help you ensure that you check your edge cases properly, and ensure you are acting within specification, then presumably you should be addressing these issues in your tests, not in production code.

Therefore the whole exercise of writing code to catch errors of this kind 'at compile-time vs runtime' is somewhat of a red herring, if not dangerous.

Having said that, I'm also guilty of frequently writing

    else: error("In theory this should never happen")

> presumably you should be addressing these issues in your tests, not in production code

What you may be missing is that this code will be guaranteed by MyPy to never actually run in production. In fact what it's effectively saying is "if this code can run, there's a type error", and therefore MyPy forces you to ensure that the code can never run.

Heh, I feel you. Test were indeed used to verify that your code runs correctly and with edge cases, and stuff like isinstance were discouraged so you wouldn't need to think about types but rather of interfaces. However I assume that a large influx of people who had experience with typed languages had changed general idea of how Python should look and be used. Oh well, times change and we all allowed it so... types it is :/

Reply on news.ycombinator.com