私はPythonライブラリを開発していますが、これはドキュメントを生成するためにsphinx.autodocを使用しています。これは自分自身を繰り返さないで、ドキュメントとコードを合意しておくのがよい方法だと思います。CPythonが標準ライブラリに `sphinx.autodoc`を使用しないのはなぜですか？
Emit reStructuredText from sphinx autodoc?へのコメントでは、「CPythonドキュメントのビルドプロセスには（意図的な選択による）オートドックが有効になっていない」ということが分かりました。
なぜ私はCPythonがそれを使用していないのだろうと、sphinx.autodocを使うことの短所は何ですか？
これは主に歴史の問題ですが、個人（プロジェクト）の好みの問題です。最近では、主にドキュメントストリングに頼って、おそらくそれらの周りに散文を追加することによって、かなり使いやすいドキュメントを得ることができます。
しかし、CPythonのドキュメントは、実際にはSphinxの存在に先立っています（実際には、Georgin BrandlはCPythonの古いドキュメントシステムを置き換えるためにSphinxの初期バージョンを書きました）。
したがって、ポリシーの問題として、ドキュメントストーリーと散文書は、オートドックの使用に依存することなく、依然として個別に管理されています。
標準ライブラリでreStucturedTextドキュメントストリングを使用できるため、autodocを使用する利点がさらに少なくなります。
最後に、ゲオルグ・ブランドルpointed out CPythonのは、あなたが標準ライブラリのバージョンが提供されることを保証するために注意する必要があり、ややユニークな立場にある：（http://www.python.org/dev/peps/pep-0287/#questions-answers PEPで287 Q & AをQ 10を参照してください） Sphinxが動いているときのドキュメントストリングは、ドキュメンテーションを生成しているのとまったく同じです。間違ったバージョンを間違って持ち込むことや、動作しているPythonビルドとドキュメントを再生成することとの間に強い依存関係を作り出すことは、あまりにも簡単です。
オートドック側では、オートドックベースのドキュメントを編集するときに、ドキュメントストリングの内容をインラインで簡単に見ることができないため、ドキュメントストリングのテキストと追加の散文がよく読まれることを確認するのが難しい一緒に。この問題は、自動ブラウザリフレッシュソリューション（http://pymolurus.blogspot.com.au/2012/01/documentation-viewer-for-sphinx.html）
のように緩和することができます。autodocは、Pythonソースファイルに適切な依存関係を自動的に追加しないため、リビルド依存関係にも問題があります。私は間違いなくdocstringsが変更されたが、Sphinxは関連する出力ファイルを再生成しなかったという問題がありました。 （これは修正されたとは信じられませんが、最近のSphinxリリースで解決された場合は、コメントで私に知らせてください。
私は2つの書き込みスタイルがまったく同じと生のドキュメンテーション文字列は、一般的にマークアップされたとき、彼らはよりもプレーンテキストとして読みやすくしているではありませんので、あなたがより良いドキュメンテーション文字列は、（別々に維持することによって、より良いドキュメントとを得ると考えている間reStructuredText）は、追加の保守作業ではかなり高いコストがかかり、不一致のリスクが高くなるというアプローチです。
したがって、ほとんどのサードパーティのPythonのプロジェクトのために、私のアドバイスは、実際には標準ライブラリの例と代わりに次のを避けるために、次のようになります。
を見るために上記のリンクのように、それは完璧なソリューションではないですが、このアプローチは最大の両方のドキュメンテーション文字列や文章のドキュメントを維持するのに重複努力のかなり保存を行います日付。
この説明をありがとうございます。個人的には、生のドキュメンテーションは、特に 'numpydoc' https://raw.github.com/numpy/numpy/master/doc/EXAMPLE_DOCSTRING.rst.txtを使用してプレーンテキストとして読みやすくなります。だから私はautodocを使い続けます。 – bmu