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 -- http://mail.python.org/mailman/listinfo/python-list