[Python-Dev] Best practice for documentation for std lib

[Guido van Rossum]

On Sun, Sep 22, 2013 at 11:44 AM, Eli Bendersky <eliben at gmail.com> wrote:

>
> On Sun, Sep 22, 2013 at 11:40 AM, Guido van Rossum <guido at python.org>wrote:
>
>> On Sun, Sep 22, 2013 at 10:25 AM, Eli Bendersky <eliben at gmail.com> wrote:
>>
>>>
>>> I think there's a general agreement in this thread that we don't intend
>>> to change the status quo. Both .rst docs and docstrings are important. The
>>> remaining question is - can we use some tool to generates parts of the
>>> former from the latter and thus avoid duplication and rot?
>>>
>>
>> I don't think that duplication is much of an issue. Natural language
>> understanding is not at the level yet where you can generate a meaningful
>> summary from a longer text fully automatically (let alone vice versa :-) so
>> I think having to write both a concise docstring and a longer more detailed
>> description for the Doc tree is not a waste of effort at all.
>>
>
> I don't think the proposal is to generate summaries from a longer text.
>

I know, I was being facetious. :-)


> AFAIU, the proposal is to embed parts of the concise docstring into the
> more verbose .rst documentation.
>

I still think that's a bad idea. Someone editing the docstring may
introduce a terminology change or some other style/grammar/flow change that
makes perfectly sense by itself but doesn't when taken in the context of
the larger .rst doc (e.g. it could introducing duplication or cause
dissonance between the two parts). Also, someone who wants to improve the
docs would have to figure out how to edit the source code if they wanted to
change some part of the docs.


> I write .rst docs quite a lot, and as such I do notice the annoying amount
> of duplication between docstrings and .rst docs. Without doubt, all the
> free-flow text and examples in .rst have to be written manually and are
> very important. But for dry method references, it's certainly interesting
> to explore the idea of writing them once in the code and then having Sphinx
> automatically insert the relevant parts into the .rst before generating
> HTML from it. For end users (those who read the docs online) the result is
> indistinguishable from what we have now. For us devs it means writing the
> same text only once and maintaining it in a single place.
>

You seem to have caught the DRY bug. But it doesn't always make sense to
factor things so that everything is said in exactly one place. (For an
example of abstraction gone wild, ironically, see docutils and sphinx. I
challenge you to find out the actual code that translates e.g.
:meth:`foobar` into <a href="(what goes here?)">foobar</a>. :-)


> Think about the new statistics module as a guinea pig. Steven will have a
> whole lot of copy-pasting to do :-)
>

The docstrings should probably be limited to the amount of text that's
currently devoted to each function in the PEP. What's currently in the
docstrings should go into the .rst docs.


> > As for rot, it's just as likely that rot occurs as a *result* of
> autogeneration.
>
> Having to edit/patch the source code in order to improve the
> > documentation most likely adds an extra barrier towards improving the
> docs.
>
> This is a valid concern, but perhaps one that can be addressed separately?
> (i.e. lowering that barrier of entry).
>

I can't see that there's any way to interpret the change you propose
(changing things so that in order to improve the HTML docs you might need
to edit both .rst and .py files) as lowering the barrier to entry. Please
give it up.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130922/5f9f495d/attachment-0001.html>