[issue8525] Display exceptions' subclasses in help()
Rob Cliffe added the comment:
On 14/07/2018 13:44, Nick Coghlan wrote:
> Nick Coghlan added the comment:
>
> Reviewing the builtins in 3.7, I get the following results for builtin
> objects that have defined subclasses immediately after interpreter startup:
>
> =
>>>> for name, obj in vars(builtins).items():
> .. if isinstance(obj, type) and name in str(obj):
> .. subclasses = type(obj).__subclasses__(obj)
> .. if subclasses:
> .. print(f"{obj}: {len(subclasses)}")
> ..
> : 1
> : 1
> : 1
> : 1
> : 132
> : 1
> : 16
> : 1
> : 4
> : 19
> : 2
> : 13
> : 3
> : 1
> : 1
> : 1
> : 3
> : 2
> : 3
> : 3
> : 1
> : 10
> : 4
> =
>
> So rather than special-casing exceptions or builtins in general, my
> inclination would be to include a section that lists up to 4 subclasses
> inline, and then adds a "... and NNN additional subclasses" trailing when
> there are more than 4 (or when there are less than 4 subclasses with public
> names, but additional private subclasses).
>
>
My 2 cents:
To use Exceptions optimally (e.g. to make the errors you trap
neither too specific nor too general), you often need to know (and
understand) the relevant part of the Exception hierarchy. In particular
you may know the name of an Exception that covers a particular use case,
but not the names of its subclasses, one of which might be more
appropriate. Exceptions are exceptional* in that the "issubclass"
relationship is vital to the way that they work. So it is USEFUL to
know ALL subclasses of a given Exception class (not just 4; in practice
there won't be more than a dozen or two). I have found myself in just
this position; in fact it impelled me to adding a "show subclasses"
feature to help() in my then current version of
Python 2. (An alternative might be a handy way of showing the complete
built-in Exception hierarchy.)
I question whether it is really useful to know all subclasses of ANY
class, or whether YAGNI. I think that, for non-Exception classes,
typically when you look at a class you may want to know its inheritance
(to understand its functionality better), but it is rare that you will
want to know what subclasses it has, if any. No doubt there are
exceptions* (perhaps you monkey-patch a class and want to know what
subclasses might be affected).
Regards
Rob Cliffe
* Pun not intended
--
___
Python tracker
<https://bugs.python.org/issue8525>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8525] Display exception's subclasses in help()
Rob Cliffe rob.cli...@btinternet.com added the comment: 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 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8525 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8525] Small enhancement to help()
Rob Cliffe rob.cli...@btinternet.com added the comment: 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 Araujomer...@netwok.org added the comment: Thank you. I uploaded your patch to Rietveld and reviewed it: http://codereview.appspot.com/3169042/ -- ___ Python trackerrep...@bugs.python.org http://bugs.python.org/issue8525 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8525 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8525] Small enhancement to help()
Rob Cliffe rob.cli...@btinternet.com added the comment:
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 Belopolskybelopol...@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 trackerrep...@bugs.python.org
http://bugs.python.org/issue8525
___
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8525
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8525] Small enhancement to help()
New submission from Rob Cliffe rob.cli...@btinternet.com: 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. -- files: pydoc.py messages: 104134 nosy: robcliffe severity: normal status: open title: Small enhancement to help() type: feature request versions: Python 2.5 Added file: http://bugs.python.org/file17075/pydoc.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8525 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
