> This is rather absurd and I won’t address it any more than to point out that many ordinary programmers intuitively grasp the basic value of safety and specificity, which is why in Python it is widely considered extremely bad practice to write `except:` or `except Exception:` even though having to specify all of the exception classes we are interested in is arguably a safety that we could override at no loss of expressiveness.<p>It takes me a while to unpack this sentence. So I hope I'm misunderstanding. I think he's saying that we could skip out on specifying the exception classes we're interested in without losing expressiveness. Expressiveness aside, this is a huge change in functionality.<p>IMO Python probably should've put some kind of damper on `except:` because it's almost never what you want. First off, I'd call this list of classes ones we're "prepared to handle" rather than "interested in." `except:` states boldly "nah, don't propagate this up the stack, I know what to do no matter what happened down there." Using `except:`/`except Exception:` is bad because it will catch "UnboundLocalError", "IndentationError" and several others that are very-nearly unhandle-able elements of the code's design. There exists a sliver of a case for a handler in __main__() or somewhere else that can log something though.<p>If he's getting at the point of Bob's article regarding static typing and testing, then I don't see how Python be anything like how it is today and still have some kind of static evaluation of Exceptions-that-could-come-from-this-call.