I was reading some of Kevlin Henney's views on naming conventions, and I realized that, of the 65 classes that make up Python's built-in exceptions, only 8 (by my count) satisfy Henney's pretty basic concept of a good Exception name:

The name should represent whatever the problem is, and should do so directly and specifically. To add Exception to the end is either redundant — so remove it — or an indication of a poor name — so rename it.

Those are:
SystemExit, KeyboardInterrupt, GeneratorExit, Exception, StopIteration, StopAsyncIteration, Warning, and BaseException (though Henney also discourages the use of "Base" in a base-class's name)

I'm sure there are others throughout the standard library too.

I always caution novice programmers to err on the side of pragmatism over dogmatic adherence to "sacred truths". To that end:

1) I realize changing built-in exception names would break backwards compatibility and probably isn't worth doing. This post is more intended as food for thought going forward and to bring more attention to Kevlin Henney's ideas.

2) I think many of the built-in exceptions are actually fine, particularly ones that represent a broad class of more specific exceptions like OSError. I don't think OSError has a specific enough name to be raised on its own (perhaps it should be abstract or otherwise not directly instantiable?), but catching error categories can be pretty helpful even if they don't lend themselves to explicit names.

I would suggest a more ideal naming scheme would be something like the following: