3 ms·
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 inste
by tpoacher 6y ago
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")
- mirko22 6y agoHeh, 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 :/
- brundolf 6y ago> 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.