Override a method but inherit the docstring

[David Stanek]

On Fri, Jul 17, 2009 at 2:58 AM, Peter Otten<__peter__ at web.de> wrote:
> Ben Finney wrote:
>
>> Howdy all,
>>
>> The following is a common idiom::
>>
>>     class FooGonk(object):
>>         def frobnicate(self):
>>             """ Frobnicate this gonk. """
>>             basic_implementation(self.wobble)
>>
>>     class BarGonk(FooGonk):
>>         def frobnicate(self):
>>             special_implementation(self.warble)
>>
>> The docstring for ‘FooGonk.frobnicate’ is, intentionally, perfectly
>> applicable to the ‘BarGonk.frobnicate’ method also. Yet in overriding
>> the method, the original docstring is not associated with it.
>>
>> Ideally there would be a way to specify that the docstring should be
>> inherited. The best I can come up with is::
>>
>>     class BarGonk(FooGonk):
>>         def frobnicate(self):
>>             special_implementation(self.warble)
>>         frobnicate.__doc__ = FooGonk.frobnicate.__doc__
>>
>> but that violates DRY (the association between BarGonk and FooGonk is
>> being repeated), puts the docstring assignment awkwardly after the end
>> of the method instead of at the beginning where docstrings normally go,
>> and reads poorly besides.
>>
>> What is the most Pythonic, DRY-adherent, and preferably least-ugly
>> approach to override a method, but have the same docstring on both
>> methods?
>
> Just thinking aloud: Write a patch for pydoc that looks up the base-class
> documentation.
>
> B.f.__doc__ will continue to return None, but
>
> help(B.f) will show something like
>
>    No documentation available for B.f.
>
>    Help for A.f:
>    yadda yadda
>
>
> Of course that might be misleading when A.f and B.f are up to something
> completely different...
>

This should never be the case. It violates LSP and would be very confusing to
readers of the code.


-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek