Issue 15731: Mechanism for inheriting docstrings and signatures (original) (raw)

Issue15731

Created on 2012-08-20 04:37 by ncoghlan, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (5)
msg168618 - (view)	Author: Alyssa Coghlan (ncoghlan) *	Date: 2012-08-20 04:37
While working on #8810, I was reminded of the problem of wanting to inherit docstrings while replacing a method implementation. The abstract base class method docstrings for tzinfo.utcoffset and tzinfo.dst are also correct for the concrete subclasses in the pure Python and the C versions. However, the docstrings currently need to be duplicated in all 3 places manually. functools.wraps already plays in this space, but arguably asserts *too much* about the relationship between components A couple of descriptors on bound and unbound methods (for __doc__ and __signature__) could have dealt with this fairly easily, but we don't have unbound methods any more :(
msg168619 - (view)	Author: Alyssa Coghlan (ncoghlan) *	Date: 2012-08-20 04:40
Slight correction: turns out this docstring appears in a lot of other places, too.
msg209706 - (view)	Author: Yury Selivanov (yselivanov) *	Date: 2014-01-30 06:20
Perhaps, something like @functools.inherit decorator could help: https://gist.github.com/1st1/8703533 (just a quick illustration).
msg259796 - (view)	Author: Serhiy Storchaka (serhiy.storchaka) *	Date: 2016-02-07 18:20
After , is it still actual?
msg259813 - (view)	Author: Alyssa Coghlan (ncoghlan) *	Date: 2016-02-08 04:28
Agreed, making it easy to follow the inheritance chains at docstring lookup time means it would be redundant to duplicate them at class definition time. Code that interrogates __doc__ directly rather than using inspect.getdoc won't benefit from the new behaviour, but that's a quality of implementation question in the code handling the introspection.