Postmodern Error Handling in Python 3.6
It&#x27;s interesting to hear that Guido is now excited by types. A few years ago his opinion was still that types can&#x27;t catch most problems. I think I will listen to that interview.<p>Personally I think types are over-hyped for most (profane) code.<p>The problem with <i>complicated</i> and&#x2F;or <i>specific</i> types (which promise to catch more errors) is, in one word, coupling. They create serious dependencies across the whole project or even across project boundaries.<p>The other problem is: one functions-guy&#x27;s URL is the next function-girl&#x27;s string. And all this up- and downcasting usually creates considerable noise. Often overzealous typing is painting oneself in a corner, creating more pain then relief. It&#x27;s like creating these totally arbitrary object-oriented inheritance-based taxonomies which might make some sense in one place of the code but totally break down in the next place.<p>But speaking about <i>primitive</i> types like <i>int</i> and <i>str</i>, or maybe <i>list of int</i> - most function arguments can accept only one of those for the code to make sense. So strategically placed type annotations can help reduce some boilerplate and put some useful barriers for error search there. While the simple-types cases are also the easy ones - the first thing you&#x27;ll notice while testing is usually that you put a <i>str</i> where an <i>int</i> was expected.