Repository navigation
Improve the use of __doc__ in pydoc #84438
Description
Activity
Currently pydoc outputs __doc__ for classes, functions, methods, properties, etc (using inspect.getdoc()). If the object itself does not have non-empty __doc__, it searches non-empty __doc__ in the class parenthesis (if the object is a class) or in the corresponding overloaded members of the class to which the object (method, property, etc) belongs.
There are several problems with this.
-
Using the docstring of a parent class is misleading in most classes, especially if it is a base or abstract class (like object, Exception, Mapping).
-
If the object does not have the __doc__ attribute, it inherits it from its class, so inspect.getdoc(1) returns the same as inspect.getdoc(int).
-
If the object has own docstring, but is not a class or function, it will be output in the section DATA without a docstring.
The following PR fixes these issues.
-
Docstrings for classes are not inherited. It is better to not output a docstring than output the wrong one.
-
inspect.getdoc() returns the object's own docstring.
-
Docstrings are always output for object with a docstring. See for example help(typing).
In future issues I'll make help(typing) even more informative.
-
vedgar commented
on Apr 12, 2020 vedgarmannequinMannequinI don't agree with 1. I use that feature a lot, I write a base class which my students must subclass to their liking, but they still expect that help(TheirClass) will give them the documentation they need.
I agree that in _some_ cases it is not helpful (but even when the base is abstract, it might be helpful). How about: we keep the current behavior, but make it clear that the docstring applies to a superclass? It might be subtle, as just changing the first line of help() output (currently it says "Help on class Derived in module ...", change it to "Help on class Base in module ..."), or write a longer message such as "Documentation for Derived not found, showing the documentation for Base". But just removing it in all cases is really a wrong thing to do.
FWIW I like the idea. There are many objects in typing module that are not classes, it would be great to display docs for them.
Inheritance of docstrings was added in bpo-15582. It works good for class members, but I now realized that doing it for class itself was a mistake. For example:
>>> import wave >>> help(wave.Error) Help on class Error in module wave:
class Error(builtins.Exception) | Common base class for all non-exit exceptions. | | Method resolution order: | Error | builtins.Exception | builtins.BaseException | builtins.object | ...
I fixed many similar issues by adding docstrings to classes, but there are even more exception classes and other classes in the stdlib for which help() gives incorrect description. I don't remember a single case when inheritance of the docstring was helpful.
Note that help() outputs the list of base class right after the docstring, so it is not hard to give an additional information, especially in interactive browser mode. If you want to inherit a docstring, you can do it explicitly:
__doc__ = BaseClass.__doc__
vedgar commented
on Apr 14, 2020 vedgarmannequinMannequinOk, I get what you're saying. But if someone writes
class B(A): # no docstring at all ... help(B)
they'll still get other elements of current help? Particularly, "Methods inherited from A" (with their docstrings)?
Yes, of course. And if it overrides some methods, but do not specify doctrings for new methods, they will be inherited from the parent class.
class A: """Base class""" def foo(self): """Some docstring""" def bar(self): """Other docstring""" class B(A): def foo(self): pass help(B)
Help on class B in module __main__:
class B(A) | Method resolution order: | B | A | builtins.object | | Methods defined here: | | foo(self) | Some docstring | |
| Methods inherited from A:
|
| bar(self)
| Other docstring
|
...vedgar commented
on Apr 14, 2020 vedgarmannequinMannequinThen I'm fine with it. Thanks.
27 remaining items
Carreau commented
on May 18, 2020 CarreaumannequinMannequinLooks like the revert is solving the issue?
It appears to do so as far as I can tell, and most test pass on nightly, the rest seem to be unrelated to changes in current 3.9.
Many thanks to Serhiy for all the work on making documentation better, and there are definitively case where a version of getowndoc, or something that discriminate where the docstring comes from would be useful.
I also agree that having _some_ ability to extend docstring would be nice but it's likely for another issue.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: