Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Override a method but inherit the docstring
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
David Stanek  
View profile  
 More options Jul 17 2009, 8:08 am
Newsgroups: comp.lang.python
From: David Stanek <dsta...@dstanek.com>
Date: Fri, 17 Jul 2009 08:08:48 -0400
Local: Fri, Jul 17 2009 8:08 am
Subject: Re: Override a method but inherit the docstring

On Fri, Jul 17, 2009 at 2:58 AM, Peter Otten<__pete...@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


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.