help() on an exception class lists the method resolution order, which is in effect the class inheritance hierarchy.  E.g. help(ArithmeticError) lists ArithmeticError, StandardError, Exception, BaseException, __builtin__.object.  It struck me it would help to find my way around if it also listed the builtin SUBclasses (if any).  Something like:
    Built-in subclasses:
        FloatingPointError
        OverflowError
        ZeroDivisionError
In fact why not do it for any class, not just exceptions?
I attach a patched version of pydoc.py - tested but only on my PC which is running Python 2.5 under Windows XP.  I have added lines 1129-1148 to the docclass method of the TextDoc class (and flagged them # [RAC] ).
(I don't pretend to understand the magic where __builtins__ is a dictionary when pydoc.py is run but becomes a module later on.  Never mind - the patch works (I believe).)
For consistency, a similar patch would also have to be made to the docclass nethod of the HTMLDoc class (which outputs HTML rather than plain text).  I have not attempted this as I don't know how it is called and hence how to test any patch, but it should be straightforward for anyone with the know-how.

2.5 is frozen. 2.6 and 3.1 are in bug-fix mode only, and 2.7 is in beta so new features are unlikely there. So I recommend doing a patch against 3.1 or even the 3.2 trunk. And of course, make sure this proposal makes sense for 3.x.

Thanks for your work, Rob. To get reviews and comments, you’ll need to submit a patch (a diff) instead of the whole file. This makes it easier to see your changes than looking for a special comment :)

This short doc should contain all the information you’ll need: http://www.python.org/dev/patches

As Terry said, 2.6 and 3.1 only get bug fixes, 2.7 and 3.2 are in beta stage and don’t get new features, so you’ll want to port your changes to the py3k branch (the trunk for the 3.x series).

Regards

Minor correction to the last comment: 3.2 is not in beta nor feature freeze.

Migrated the patch to the 3.x trunk and added three tests.

Thank you.  I uploaded your patch to Rietveld and reviewed it: http://codereview.appspot.com/3169042/

The following passes tests in elp_8525.patch, but is much simpler:

===================================================================
--- Lib/pydoc.py	(revision 86600)
+++ Lib/pydoc.py	(working copy)
@@ -1139,6 +1139,15 @@
                 push('    ' + makename(base))
             push('')
 
+        # List the built-in subclasses, if any:
+        subclasses = [cls.__name__ for cls in object.__subclasses__()
+                      if cls.__module__ == 'builtins']
+        if subclasses:
+            push("Built-in subclasses:")
+            for subclassname in sorted(subclasses):
+                push('    ' + subclassname)
+            push('')
+
         # Cute little class to pump out a horizontal rule between sections.
         class HorizontalRule:
             def __init__(self):

Thanks for your work.  Glad if I have made a contribution to Python, 
however small.
Rob Cliffe

On 22/11/2010 00:26, Éric Araujo wrote:
> Éric Araujo<merwok@netwok.org>  added the comment:
>
> Thank you.  I uploaded your patch to Rietveld and reviewed it: http://codereview.appspot.com/3169042/
>
> ----------
>
> _______________________________________
> Python tracker<report@bugs.python.org>
> <http://bugs.python.org/issue8525>
> _______________________________________
>

I would not be at all surprised if my patch could be simplified (in fact 
I'd be surprised if it couldn't).
However, I did try out your version on Python 2.5 specifically, and it 
did not work for me.
Trying it out on help(Exception), the relevant members of 
object.__subclasses__() viz.
<type 'exceptions.StandardError'>, <type 'exceptions.StopIteration'>  etc.
had a __module__attribute which equalled 'exceptions', not 'builtins'.
Best wishes
Rob Cliffe

On 22/11/2010 01:33, Alexander Belopolsky wrote:
> Alexander Belopolsky<belopolsky@users.sourceforge.net>  added the comment:
>
> The following passes tests in elp_8525.patch, but is much simpler:
>
> ===================================================================
> --- Lib/pydoc.py	(revision 86600)
> +++ Lib/pydoc.py	(working copy)
> @@ -1139,6 +1139,15 @@
>                   push('    ' + makename(base))
>               push('')
>
> +        # List the built-in subclasses, if any:
> +        subclasses = [cls.__name__ for cls in object.__subclasses__()
> +                      if cls.__module__ == 'builtins']
> +        if subclasses:
> +            push("Built-in subclasses:")
> +            for subclassname in sorted(subclasses):
> +                push('    ' + subclassname)
> +            push('')
> +
>           # Cute little class to pump out a horizontal rule between sections.
>           class HorizontalRule:
>               def __init__(self):
>
> ----------
> nosy: +belopolsky
>
> _______________________________________
> Python tracker<report@bugs.python.org>
> <http://bugs.python.org/issue8525>
> _______________________________________
>

New features can only go into 3.2, so you have to test with an updated checkout of the Subversion branch named py3k.  See the link I have in a previous message.

(P.S. Would you be so kind as to edit quoted text out of your replies?  It’s unnecessary noise.  Thanks in advance.)

The proposal is to display builtin subclasses as for example:

>>> help(ArithmeticError)
class ArithmeticError(Exception)
 |  Base class for arithmetic errors.
 |  
 |  Method resolution order:
 |      ArithmeticError
 |      Exception
 |      BaseException
 |      object
 |  
 |  Built-in subclasses:
 |      FloatingPointError
 |      OverflowError
 |      ZeroDivisionError

Note that this really affects only exceptions because no other builtin class has builtin subclasses.  (dict has subclasses in collections, but not in builtins.)

Exception hierarchy is presented in the reference manual at

http://docs.python.org/dev/library/exceptions.html?#exception-hierarchy

I wonder if rather than having MRO and subclasses sections, we should just present a portion of the exception hierarchy including the given exception, all its bases and direct subclasses:

object
 |
BaseException
 |
Exception
 |
*ArithmeticError*
 |
 +-- FloatingPointError
 +-- OverflowError
 +-- ZeroDivisionError

Didn’t the first message ask for the feature to be extended to non-exceptions classes?  “Built-in” subclasses is a red herring, to me the feature is: display subclasses.  In the text output you can use the search feature of your pager to jump to a subclass, in the HTML output it would be a helpful link.

On Thu, Dec 2, 2010 at 9:56 PM, Éric Araujo <report@bugs.python.org> wrote:
..
> Didn’t the first message ask for the feature to be extended to non-exceptions classes?  “Built-in”
> subclasses is a red herring, to me the feature is: display subclasses.  In the text output you can use
> the search feature of your pager to jump to a subclass, in the HTML output it would be a helpful link.

If we don't restrict to builtins, then the display will depend on what
modules are currently loaded and will be useless for command line use
unless all subclasses are defined in the same module.

Yes, I imagine the feature to be useful to find subclasses defined in the same module.  Rob, am I misunderstanding your original request?

Originally I only had built-in classes in mind (with Exceptions being 
IMO the most obvious example of a built-in class hierarchy that it is 
useful to find your way around).  But if the idea can be extended to 
other classes, well, great.
Rob Cliffe