views:

152

answers:

2

I prefer to document each parameter (as needed) on the same line where I declare the parameter in order to apply D.R.Y.

If I have code like this:

def foo(
        flab_nickers, # a series of under garments to process
        has_polka_dots=False,
        needs_pressing=False  # Whether the list of garments should all be pressed
   ):
    ...

How can I avoid repeating the parameters in the doc string and retain the parameter explanations?

I want to avoid:

def foo(
        flab_nickers, # a series of under garments to process
        has_polka_dots=False,
        needs_pressing=False  # Whether the list of garments should all be pressed
    ):
    '''Foo does whatever.

    * flab_nickers - a series of under garments to process
    * needs_pressing - Whether the list of garments should all be pressed.
      [Default False.]

Is this possible in python 2.6 or python 3 with some sort of decorator manipulation? Is there some other way?

+2  A: 

I would do this.

Starting with this code.

def foo(
        flab_nickers, # a series of under garments to process
        has_polka_dots=False,
        needs_pressing=False  # Whether the list of garments should all be pressed
   ):
    ...

I would write a parser that grabs the function parameter definitions and builds the following:

def foo(
        flab_nickers, 
        has_polka_dots=False,
        needs_pressing=False,
   ):
   """foo

   :param flab_nickers: a series of under garments to process
   :param has_polka_dots: default False
   :param needs_pressing: default False, Whether the list of garments should all be pressed
   """
    ...

That's some pretty straight-forward regex processing of the various arguments string patterns to fill in the documentation template.

Note the extra comma in the code; that's just to make things consistent. It does no harm, and it might simplify things in the future.

You can also try and use the Python compiler to get a parse tree, revise it and emit the update code. I've done this for other languages (not Python), so I know a little bit about it, but don't know how well supported it is in Python.

Also, this is a one-time transformation.

The original in-line comments in the function definition don't really follow DRY because it's a comment, in an informal language, and unusable by any but the most sophisticated tools.

The Sphinx comments are closer to DRY because they're in the RST markup language, making them much easier to process using ordinary text-parsing tools in docutils.

It's only DRY if tools can make use of it.

S.Lott
A: 

You can't do that without a preprocessor, as comments don't exist for Python once the source has been compiled. To avoid repeating yourself, remove the comments and document the parameters only in the docstring, this is the standard way to document your arguments.

Luper Rouch
Maybe it is a bad habit, but I acquired the taste for inline documentation after using Verilog (hardware design language) where parameter lists for top level modules can have a hundred parameters. So if you put the Verilog parameter documentation away from the actual parameter documentation line, they could be separated by 100 lines, which is really bad for maintainability.
Ross Rogers
And for these top level verilog modules you have many people modifying this file, so you can't rely on people being good citizens. Anyways, you may be right. It could be a square peg in a round hole.
Ross Rogers
@Ross Rogers: Sphinx will identify the bad citizens for you. If the :param name: doesn't match the actual arguments, you get warnings.
S.Lott
@Ross Rogers: Yes: Square Peg Round Hole. 100's of parameter lists in Python would be a code smell. If you've got parameter lists like that, you're probably doing something wrong.
S.Lott
@Lott. - I don't have 100's of parameters :-) I was just explaining where this hare-brained notion came from. A certain method does have 7 args. In Verilog, however 100 parameters is absolutely necessary because cross-module references can't synthesize to gates with certain hardware synthesis tools.
Ross Rogers
@Ross Rogers: I understood that 100's was Verilog, not Python. I was saying that 100's is *so* atypical of Python that (a) it should be rethought, and (b) that's why simple RST `:param name:` documentation in the docstring is never a problem in Python.
S.Lott