This is a UX problem folks: dynamic unbounded lists are inherently problematic in a line based information display.

For methods on a class, there's the natural constraint that broad class APIs are a problem for a variety of reasons, but there's no such design constraint for exception hierarchies.

In a Fedora Python 3.6 shell (with the Fedora abrt exception handling hook loaded), Exception has 31 subclasses, and OSError has 17.

In a 3.6 shell venv (with no Fedora abrt hook), those numbers are 20 and 13. 

But if you import assorted Django modules then the number of Exception subclasses grows significantly, while the number of OSError subclasses grows slightly:

>>> import django
>>> len(list(pkgutil.iter_modules(django.__path__)))
17
>>> len(Exception.__subclasses__())
76
>>> len(OSError.__subclasses__())
22

Having "help(Exception)" list 50+ different Django exceptions is unlikely to be informative for anyone.


In many ways, Python 2 was actually better in this regard, since you could just do "import exceptions; help(exceptions)" to get a nice overview of the full exception hierarchy using the standard logic for displaying.


The closest Python 3 currently gets to that is "import builtins; help(builtins)", which is significantly harder to discover.