title: Why is type checking in Python considered to be a bad idea?
body: <p>Many make that comment, but no one offers a reason why it is bad.</p>
  
  <p>How else to catch user input errors? Wait for some code somewhere else to "throw an exception?" Why is it not better to catch an error immediately?</p>
  
  <p>For instance, an (ab)user types in 17.6 for an expected integer response. It is clearly an error, getting a <em>type</em> of <code>float</code> for an expected <em>type</em> of <code>int</code> (just to be clear?).</p>
  
  <p>Or, say, that (ab)user even enters 17/6 for the intended <code>float</code>. 17/6 <em>is</em> a <code>float</code>, so it would be hard to catch this error, if one waited for the data to get where it is actually used.</p>
  
  <p>I do not understand the premise.</p>
  
  <p>===========================
  The following is an edit based on the many (very good) replies - and THANKS for all of them!</p>
  
  <p>First, I believe that ALL coding <em>styles</em> are based upon opinions of people that have learned to have those opinions based on some error they have encountered. So, yes, by definition, as this is a coding style question, all answers are likely based upon opinions, or experience which led there.</p>
  
  <p>Second, testing type after input, at a function, is now something I understand from the comments. Many thanks for the examples and explanations.</p>
  
  <p>Third, perhaps the "testing for type is bad" ideology should be somewhat expounded upon to mean AFTER testing inputs, as many comments pointed towards. It was a blanket statement stated in many responses to searches I have done, trying to test the human inputs obtained in my code.</p>
  
  <p>Once again, many thanks for all of the knowledge y'all have shared.</p>