/usr/share/doc/docutils-doc/docs/dev/enthought-plan.html is in docutils-doc 0.14+dfsg-3.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 | <?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Docutils 0.14: http://docutils.sourceforge.net/" />
<title>Plan for Enthought API Documentation Tool</title>
<meta name="author" content="David Goodger" />
<meta name="date" content="2012-01-03" />
<meta name="copyright" content="2004 by Enthought, Inc." />
<link rel="stylesheet" href="../../css/html4css1.css" type="text/css" />
</head>
<body>
<div class="document" id="plan-for-enthought-api-documentation-tool">
<h1 class="title">Plan for Enthought API Documentation Tool</h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr><th class="docinfo-name">Author:</th>
<td>David Goodger</td></tr>
<tr><th class="docinfo-name">Contact:</th>
<td><a class="first last reference external" href="mailto:docutils-develop@lists.sourceforge.net">docutils-develop@lists.sourceforge.net</a></td></tr>
<tr><th class="docinfo-name">Date:</th>
<td>2012-01-03</td></tr>
<tr><th class="docinfo-name">Revision:</th>
<td>7302</td></tr>
<tr><th class="docinfo-name">Copyright:</th>
<td>2004 by <a class="reference external" href="http://www.enthought.com">Enthought, Inc.</a></td></tr>
<tr class="license field"><th class="docinfo-name">License:</th><td class="field-body"><a class="reference external" href="http://docutils.sf.net/licenses/enthought.txt">Enthought License</a> (BSD-style)</td>
</tr>
</tbody>
</table>
<p>This document should be read in conjunction with the <a class="reference external" href="enthought-rfp.html">Enthought API
Documentation Tool RFP</a> prepared by Janet Swisher.</p>
<div class="contents topic" id="contents">
<p class="topic-title first">Contents</p>
<ul class="auto-toc simple">
<li><a class="reference internal" href="#introduction" id="id5">1 Introduction</a></li>
<li><a class="reference internal" href="#development-plan" id="id6">2 Development Plan</a></li>
<li><a class="reference internal" href="#repository" id="id7">3 Repository</a></li>
<li><a class="reference internal" href="#copyright-license" id="id8">4 Copyright & License</a></li>
<li><a class="reference internal" href="#proposed-changes-to-restructuredtext" id="id9">5 Proposed Changes to reStructuredText</a><ul class="auto-toc">
<li><a class="reference internal" href="#doc-comment-syntax" id="id10">5.1 Doc Comment Syntax</a><ul class="auto-toc">
<li><a class="reference internal" href="#recommendation" id="id11">5.1.1 Recommendation</a></li>
<li><a class="reference internal" href="#update" id="id12">5.1.2 Update</a></li>
</ul>
</li>
<li><a class="reference internal" href="#docstring-density-whitespace-minimization" id="id13">5.2 Docstring Density & Whitespace Minimization</a><ul class="auto-toc">
<li><a class="reference internal" href="#id4" id="id14">5.2.1 Recommendation</a></li>
</ul>
</li>
</ul>
</li>
</ul>
</div>
<div class="section" id="introduction">
<h1><a class="toc-backref" href="#id5">1 Introduction</a></h1>
<p>In March 2004 at I met Eric Jones, president and CTO of <a class="reference external" href="http://www.enthought.com">Enthought,
Inc.</a>, at <a class="reference external" href="http://pycon.org/dc2004/">PyCon 2004</a> in Washington DC. He told me that Enthought
was using <a class="reference external" href="http://docutils.sf.net/rst.html">reStructuredText</a> for source code documentation, but they
had some issues. He asked if I'd be interested in doing some work on
a customized API documentation tool. Shortly after PyCon, Janet
Swisher, Enthought's senior technical writer, contacted me to work out
details. Some email, a trip to Austin in May, and plenty of Texas
hospitality later, we had a project. This document will record the
details, milestones, and evolution of the project.</p>
<p>In a nutshell, Enthought is sponsoring the implementation of an open
source API documentation tool that meets their needs. Fortuitously,
their needs coincide well with the "Python Source Reader" description
in <a class="reference external" href="http://docutils.sf.net/docs/peps/pep-0258.html#python-source-reader">PEP 258</a>. In other words, Enthought is funding some significant
improvements to Docutils, improvements that were planned but never
implemented due to time and other constraints. The implementation
will take place gradually over several months, on a part-time basis.</p>
<p>This is an ideal example of cooperation between a corporation and an
open-source project. The corporation, the project, I personally, and
the community all benefit. Enthought, whose commitment to open source
is also evidenced by their sponsorship of <a class="reference external" href="http://www.scipy.org/">SciPy</a>, benefits by
obtaining a useful piece of software, much more quickly than would
have been possible without their support. Docutils benefits directly
from the implementation of one of its core subsystems. I benefit from
the funding, which allows me to justify the long hours to my wife and
family. All the corporations, projects, and individuals that make up
the community will benefit from the end result, which will be great.</p>
<p>All that's left now is to actually do the work!</p>
</div>
<div class="section" id="development-plan">
<h1><a class="toc-backref" href="#id6">2 Development Plan</a></h1>
<ol class="arabic simple">
<li>Analyze prior art, most notably <a class="reference external" href="http://epydoc.sourceforge.net/">Epydoc</a> and <a class="reference external" href="http://happydoc.sourceforge.net/">HappyDoc</a>, to see how
they do what they do. I have no desire to reinvent wheels
unnecessarily. I want to take the best ideas from each tool,
combined with the outline in <a class="reference external" href="http://docutils.sf.net/docs/peps/pep-0258.html#python-source-reader">PEP 258</a> (which will evolve), and
build at least the foundation of the definitive Python
auto-documentation tool.</li>
<li>Decide on a base platform. The best way to achieve Enthought's
goals in a reasonable time frame may be to extend Epydoc or
HappyDoc. Or it may be necessary to start fresh.</li>
<li>Extend the reStructuredText parser. See <a class="reference internal" href="#proposed-changes-to-restructuredtext">Proposed Changes to
reStructuredText</a> below.</li>
<li>Depending on the base platform chosen, build or extend the
docstring & doc comment extraction tool. This may be the biggest
part of the project, but I won't be able to break it down into
details until more is known.</li>
</ol>
</div>
<div class="section" id="repository">
<h1><a class="toc-backref" href="#id7">3 Repository</a></h1>
<p>If possible, all software and documentation files will be stored in
the Subversion repository of Docutils and/or the base project, which
are all publicly-available via anonymous pserver access.</p>
<p>The Docutils project is very open about granting Subversion write
access; so far, everyone who asked has been given access. Any
Enthought staff member who would like Subversion write access will get
it.</p>
<p>If either Epydoc or HappyDoc is chosen as the base platform, I will
ask the project's administrator for CVS access for myself and any
Enthought staff member who wants it. If sufficient access is not
granted -- although I doubt that there would be any problem -- we may
have to begin a fork, which could be hosted on SourceForge, on
Enthought's Subversion server, or anywhere else deemed appropriate.</p>
</div>
<div class="section" id="copyright-license">
<h1><a class="toc-backref" href="#id8">4 Copyright & License</a></h1>
<p>Most existing Docutils files have been placed in the public domain, as
follows:</p>
<pre class="literal-block">
:Copyright: This document has been placed in the public domain.
</pre>
<p>This is in conjunction with the "Public Domain Dedication" section of
<a class="reference external" href="http://docutils.sourceforge.net/COPYING.html">COPYING.txt</a>.</p>
<p>The code and documentation originating from Enthought funding will
have Enthought's copyright and license declaration. While I will try
to keep Enthought-specific code and documentation separate from the
existing files, there will inevitably be cases where it makes the most
sense to extend existing files.</p>
<p>I propose the following:</p>
<ol class="arabic">
<li><p class="first">New files related to this Enthought-funded work will be identified
with the following field-list headers:</p>
<pre class="literal-block">
:Copyright: 2004 by Enthought, Inc.
:License: Enthought License (BSD Style)
</pre>
<p>The license field text will be linked to the license file itself.</p>
</li>
<li><p class="first">For significant or major changes to an existing file (more than 10%
change), the headers shall change as follows (for example):</p>
<pre class="literal-block">
:Copyright: 2001-2004 by David Goodger
:Copyright: 2004 by Enthought, Inc.
:License: BSD-style
</pre>
<p>If the Enthought-funded portion becomes greater than the previously
existing portion, Enthought's copyright line will be shown first.</p>
</li>
<li><p class="first">In cases of insignificant or minor changes to an existing file
(less than 10% change), the public domain status shall remain
unchanged.</p>
</li>
</ol>
<p>A section describing all of this will be added to the Docutils
<a class="reference external" href="http://docutils.sf.net/COPYING.html">COPYING</a> instructions file.</p>
<p>If another project is chosen as the base project, similar changes
would be made to their files, subject to negotiation.</p>
</div>
<div class="section" id="proposed-changes-to-restructuredtext">
<h1><a class="toc-backref" href="#id9">5 Proposed Changes to reStructuredText</a></h1>
<div class="section" id="doc-comment-syntax">
<h2><a class="toc-backref" href="#id10">5.1 Doc Comment Syntax</a></h2>
<p>The "traits" construct is implemented as dictionaries, where
standalone strings would be Python syntax errors. Therefore traits
require documentation in comments. We also need a way to
differentiate between ordinary "internal" comments and documentation
comments (doc comments).</p>
<p>Javadoc uses the following syntax for doc comments:</p>
<pre class="literal-block">
/**
* The first line of a multi-line doc comment begins with a slash
* and *two* asterisks. The doc comment ends normally.
*/
</pre>
<p>Python doesn't have multi-line comments; only single-line. A similar
convention in Python might look like this:</p>
<pre class="literal-block">
##
# The first line of a doc comment begins with *two* hash marks.
# The doc comment ends with the first non-comment line.
'data' : AnyValue,
## The double-hash-marks could occur on the first line of text,
# saving a line in the source.
'data' : AnyValue,
</pre>
<p>How to indicate the end of the doc comment?</p>
<pre class="literal-block">
##
# The first line of a doc comment begins with *two* hash marks.
# The doc comment ends with the first non-comment line, or another
# double-hash-mark.
##
# This is an ordinary, internal, non-doc comment.
'data' : AnyValue,
## First line of a doc comment, terse syntax.
# Second (and last) line. Ends here: ##
# This is an ordinary, internal, non-doc comment.
'data' : AnyValue,
</pre>
<p>Or do we even need to worry about this case? A simple blank line
could be used:</p>
<pre class="literal-block">
## First line of a doc comment, terse syntax.
# Second (and last) line. Ends with a blank line.
# This is an ordinary, internal, non-doc comment.
'data' : AnyValue,
</pre>
<p>Other possibilities:</p>
<pre class="literal-block">
#" Instead of double-hash-marks, we could use a hash mark and a
# quotation mark to begin the doc comment.
'data' : AnyValue,
## We could require double-hash-marks on every line. This has the
## added benefit of delimiting the *end* of the doc comment, as
## well as working well with line wrapping in Emacs
## ("fill-paragraph" command).
# Ordinary non-doc comment.
'data' : AnyValue,
#" A hash mark and a quotation mark on each line looks funny, and
#" it doesn't work well with line wrapping in Emacs.
'data' : AnyValue,
</pre>
<p>These styles (repeated on each line) work well with line wrapping in
Emacs:</p>
<pre class="literal-block">
## #> #| #- #% #! #*
</pre>
<p>These styles do <em>not</em> work well with line wrapping in Emacs:</p>
<pre class="literal-block">
#" #' #: #) #. #/ #@ #$ #^ #= #+ #_ #~
</pre>
<p>The style of doc comment indicator used could be a runtime, global
and/or per-module setting. That may add more complexity than it's
worth though.</p>
<div class="section" id="recommendation">
<h3><a class="toc-backref" href="#id11">5.1.1 Recommendation</a></h3>
<p>I recommend adopting "#*" on every line:</p>
<pre class="literal-block">
# This is an ordinary non-doc comment.
#* This is a documentation comment, with an asterisk after the
#* hash marks on every line.
'data' : AnyValue,
</pre>
<p>I initially recommended adopting double-hash-marks:</p>
<pre class="literal-block">
# This is an ordinary non-doc comment.
## This is a documentation comment, with double-hash-marks on
## every line.
'data' : AnyValue,
</pre>
<p>But Janet Swisher rightly pointed out that this could collide with
ordinary comments that are then block-commented. This applies to
double-hash-marks on the first line only as well. So they're out.</p>
<p>On the other hand, the JavaDoc-comment style ("##" on the first line
only, "#" after that) is used in Fredrik Lundh's <a class="reference external" href="http://effbot.org/zone/pythondoc.htm">PythonDoc</a>. It may
be worthwhile to conform to this syntax, reinforcing it as a standard.
PythonDoc does not support terse doc comments (text after "##" on the
first line).</p>
</div>
<div class="section" id="update">
<h3><a class="toc-backref" href="#id12">5.1.2 Update</a></h3>
<p>Enthought's Traits system has switched to a metaclass base, and traits
are now defined via ordinary attributes. Therefore doc comments are
no longer absolutely necessary; attribute docstrings will suffice.
Doc comments may still be desirable though, since they allow
documentation to precede the thing being documented.</p>
</div>
</div>
<div class="section" id="docstring-density-whitespace-minimization">
<h2><a class="toc-backref" href="#id13">5.2 Docstring Density & Whitespace Minimization</a></h2>
<p>One problem with extensively documented classes & functions, is that
there is a lot of screen space wasted on whitespace. Here's some
current Enthought code (from lib/cp/fluids/gassmann.py):</p>
<pre class="literal-block">
def max_gas(temperature, pressure, api, specific_gravity=.56):
"""
Computes the maximum dissolved gas in oil using Batzle and
Wang (1992).
Parameters
----------
temperature : sequence
Temperature in degrees Celsius
pressure : sequence
Pressure in MPa
api : sequence
Stock tank oil API
specific_gravity : sequence
Specific gravity of gas at STP, default is .56
Returns
-------
max_gor : sequence
Maximum dissolved gas in liters/liter
Description
-----------
This estimate is based on equations given by Mavko, Mukerji,
and Dvorkin, (1998, pp. 218-219, or 2003, p. 236) obtained
originally from Batzle and Wang (1992).
"""
code...
</pre>
<p>The docstring is 24 lines long.</p>
<p>Rather than using subsections, field lists (which exist now) can save
6 lines:</p>
<pre class="literal-block">
def max_gas(temperature, pressure, api, specific_gravity=.56):
"""
Computes the maximum dissolved gas in oil using Batzle and
Wang (1992).
:Parameters:
temperature : sequence
Temperature in degrees Celsius
pressure : sequence
Pressure in MPa
api : sequence
Stock tank oil API
specific_gravity : sequence
Specific gravity of gas at STP, default is .56
:Returns:
max_gor : sequence
Maximum dissolved gas in liters/liter
:Description: This estimate is based on equations given by
Mavko, Mukerji, and Dvorkin, (1998, pp. 218-219, or 2003,
p. 236) obtained originally from Batzle and Wang (1992).
"""
code...
</pre>
<p>As with the "Description" field above, field bodies may begin on the
same line as the field name, which also saves space.</p>
<p>The output for field lists is typically a table structure. For
example:</p>
<blockquote>
<table class="docutils field-list" frame="void" rules="none">
<col class="field-name" />
<col class="field-body" />
<tbody valign="top">
<tr class="field"><th class="field-name">Parameters:</th><td class="field-body"><dl class="first docutils">
<dt>temperature <span class="classifier-delimiter">:</span> <span class="classifier">sequence</span></dt>
<dd><p class="first last">Temperature in degrees Celsius</p>
</dd>
<dt>pressure <span class="classifier-delimiter">:</span> <span class="classifier">sequence</span></dt>
<dd><p class="first last">Pressure in MPa</p>
</dd>
<dt>api <span class="classifier-delimiter">:</span> <span class="classifier">sequence</span></dt>
<dd><p class="first last">Stock tank oil API</p>
</dd>
<dt>specific_gravity <span class="classifier-delimiter">:</span> <span class="classifier">sequence</span></dt>
<dd><p class="first last">Specific gravity of gas at STP, default is .56</p>
</dd>
</dl>
</td>
</tr>
<tr class="field"><th class="field-name">Returns:</th><td class="field-body"><dl class="first docutils">
<dt>max_gor <span class="classifier-delimiter">:</span> <span class="classifier">sequence</span></dt>
<dd><p class="first last">Maximum dissolved gas in liters/liter</p>
</dd>
</dl>
</td>
</tr>
<tr class="field"><th class="field-name">Description:</th><td class="field-body"><p class="first last">This estimate is based on equations given by Mavko,
Mukerji, and Dvorkin, (1998, pp. 218-219, or 2003, p. 236)
obtained originally from Batzle and Wang (1992).</p>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p>But the definition lists describing the parameters and return values
are still wasteful of space. There are a lot of half-filled lines.</p>
<p>Definition lists are currently defined as:</p>
<pre class="literal-block">
term : classifier
definition
</pre>
<p>Where the classifier part is optional. Ideas for improvements:</p>
<ol class="arabic">
<li><p class="first">We could allow multiple classifiers:</p>
<pre class="literal-block">
term : classifier one : two : three ...
definition
</pre>
</li>
<li><p class="first">We could allow the definition on the same line as the term, using
some embedded/inline markup:</p>
<ul>
<li><p class="first">"--" could be used, but only in limited and well-known contexts:</p>
<pre class="literal-block">
term -- definition
</pre>
<p>This is the syntax used by StructuredText (one of
reStructuredText's predecessors). It was not adopted for
reStructuredText because it is ambiguous -- people often use "--"
in their text, as I just did. But given a constrained context,
the ambiguity would be acceptable (or would it?). That context
would be: in docstrings, within a field list, perhaps only with
certain well-defined field names (parameters, returns).</p>
</li>
<li><p class="first">The "constrained context" above isn't really enough to make the
ambiguity acceptable. Instead, a slightly more verbose but far
less ambiguous syntax is possible:</p>
<pre class="literal-block">
term === definition
</pre>
<p>This syntax has advantages. Equals signs lend themselves to the
connotation of "definition". And whereas one or two equals signs
are commonly used in program code, three equals signs in a row
have no conflicting meanings that I know of. (Update: there
<em>are</em> uses out there.)</p>
</li>
</ul>
<p>The problem with this approach is that using inline markup for
structure is inherently ambiguous in reStructuredText. For
example, writing <em>about</em> definition lists would be difficult:</p>
<pre class="literal-block">
``term === definition`` is an example of a compact definition list item
</pre>
<p>The parser checks for structural markup before it does inline
markup processing. But the "===" should be protected by its inline
literal context.</p>
</li>
<li><p class="first">We could allow the definition on the same line as the term, using
structural markup. A variation on bullet lists would work well:</p>
<pre class="literal-block">
: term :: definition
: another term :: and a definition that
wraps across lines
</pre>
<p>Some ambiguity remains:</p>
<pre class="literal-block">
: term ``containing :: double colons`` :: definition
</pre>
<p>But the likelihood of such cases is negligible, and they can be
covered in the documentation.</p>
<p>Other possibilities for the definition delimiter include:</p>
<pre class="literal-block">
: term : classifier -- definition
: term : classifier --- definition
: term : classifier : : definition
: term : classifier === definition
</pre>
</li>
</ol>
<p>The third idea currently has the best chance of being adopted and
implemented.</p>
<div class="section" id="id4">
<h3><a class="toc-backref" href="#id14">5.2.1 Recommendation</a></h3>
<p>Combining these ideas, the function definition becomes:</p>
<pre class="literal-block">
def max_gas(temperature, pressure, api, specific_gravity=.56):
"""
Computes the maximum dissolved gas in oil using Batzle and
Wang (1992).
:Parameters:
: temperature : sequence :: Temperature in degrees Celsius
: pressure : sequence :: Pressure in MPa
: api : sequence :: Stock tank oil API
: specific_gravity : sequence :: Specific gravity of gas at
STP, default is .56
:Returns:
: max_gor : sequence :: Maximum dissolved gas in liters/liter
:Description: This estimate is based on equations given by
Mavko, Mukerji, and Dvorkin, (1998, pp. 218-219, or 2003,
p. 236) obtained originally from Batzle and Wang (1992).
"""
code...
</pre>
<p>The docstring is reduced to 14 lines, from the original 24. For
longer docstrings with many parameters and return values, the
difference would be more significant.</p>
</div>
</div>
</div>
</div>
</body>
</html>
|