This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients Rodolpho.Eckhardt, belopolsky, brian.curtin, eric.araujo, georg.brandl, henriquebastos, robcliffe, ron_adam, terry.reedy
Date 2010-11-23.05:34:26
SpamBayes Score 1.4067327e-06
Marked as misclassified No
Message-id <1290490469.43.0.24195081406.issue8525@psf.upfronthosting.co.za>
In-reply-to
Content
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
History
Date User Action Args
2010-11-23 05:34:29belopolskysetrecipients: + belopolsky, georg.brandl, terry.reedy, ron_adam, eric.araujo, brian.curtin, robcliffe, henriquebastos, Rodolpho.Eckhardt
2010-11-23 05:34:29belopolskysetmessageid: <1290490469.43.0.24195081406.issue8525@psf.upfronthosting.co.za>
2010-11-23 05:34:26belopolskylinkissue8525 messages
2010-11-23 05:34:26belopolskycreate