== Dangerously over-broad error catching One of the stock pieces of advice about writing Python code is that basic error checks should be handled by catching the exception that trying to do the operation generates, instead of through explicit checks beforehand. For example, if you are getting the value for a key from a dictionary (what some other languages call a hash), you don't bother checking to see if the key is in the dictionary beforehand; you just try to get the value. This code might be written like this (especially in examples): > try: > result = some_func(dict[key]) > except KeyError: > # key isn't in dict. > result = None Unfortunately, this code has a serious, somewhat subtle problem; the _try: ... except_ clause is too broad. You probably wanted _result_ set to None just if _dict[key]_ didn't exist. But with this code, it will also happen if ((some_func)) or anything it calls raises an otherwise uncaught KeyError exception. Such uncaught KeyError exceptions are probably real bugs that you want to fix, but this code is hiding them. You should be doing as little as possible in try/except blocks that catch general errors, because that way you minimize the risk that you're accidentally sweeping unrelated errors under the carpet. It follows that the worst version of this is to write a try/except block using '_except:_' so that it catches *all* exceptions. Please don't be that lazy.