From c6a87ac3b3db32003899bd2a9d45f96c0fee2193 Mon Sep 17 00:00:00 2001 From: goodger Date: Thu, 5 Jan 2006 23:28:53 +0000 Subject: fixed markup bugs in docstrings; now works with Endo git-svn-id: http://svn.code.sf.net/p/docutils/code/trunk/docutils@4242 929543f6-e4f2-0310-98a6-ba3bd3dd1d04 --- docutils/readers/python/moduleparser.py | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'docutils/readers/python/moduleparser.py') diff --git a/docutils/readers/python/moduleparser.py b/docutils/readers/python/moduleparser.py index 8fd7ed67b..03d57c948 100644 --- a/docutils/readers/python/moduleparser.py +++ b/docutils/readers/python/moduleparser.py @@ -140,7 +140,7 @@ number from the compiler.parse() AST, and the TokenParser.rhs(lineno) method provides the rest. The Docutils Python reader component will transform this module doctree into a -Python-specific Docutils doctree, and then a `stylist transform`_ will +Python-specific Docutils doctree, and then a "stylist transform" will further transform it into a generic doctree. Namespaces will have to be compiled for each of the scopes, but I'm not certain at what stage of processing. @@ -148,6 +148,8 @@ processing. It's very important to keep all docstring processing out of this, so that it's a completely generic and not tool-specific. +:: + > Why perform all of those transformations? Why not go from the AST to a > generic doctree? Or, even from the AST to the final output? @@ -176,7 +178,7 @@ from the Reader component itself. One stylist transform could produce HappyDoc-like output, another could produce output similar to module docs in the Python library reference manual, and so on. -It's for exactly this reason: +It's for exactly this reason:: >> It's very important to keep all docstring processing out of this, so that >> it's a completely generic and not tool-specific. -- cgit v1.2.1