File: README.txt

package info (click to toggle)
python-happydoc 2.0-2
  • links: PTS
  • area: main
  • in suites: woody
  • size: 4,176 kB
  • ctags: 3,347
  • sloc: python: 11,321; makefile: 88; sh: 77
file content (279 lines) | stat: -rw-r--r-- 10,521 bytes parent folder | download
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
HappyDoc Documentation Extraction Tool

  HappyDoc is a tool for extracting documentation from Python source
  code.  It differs from other such applications by the fact that it
  uses the parse tree for a module to derive the information used in
  its output, rather that importing the module directly.  This allows
  the user to generate documentation for modules which need special
  context to be imported.


Download

  Download the latest version of
  "HappyDoc":http://sourceforge.net/projects/happydoc/ from
  "SourceForge":http://sourceforge.net .

  Thanks to <A href="http://sourceforge.net"> <IMG
  src="http://sourceforge.net/sflogo.php?group_id=9678" width="88"
  height="31" border="0" alt="SourceForge"></A> for hosting
  HappyDoc development.


Installation

  HappyDoc uses the Distutils package for installation.  Unpack the
  tarball downloaded from SourceForge in a temporary directory.  Then
  run::

    % python ./setup.py install

  to install the package in a central location.  Alternatively,
  HappyDoc can be run directly from its unpacked distribution archive.
  Use this method if you do not have write access to the
  'site-packages' directory for your Python installation.

  For the Impatient

    After installation, the HappyDoc command-line application should
    be in your path.  Simply run 'happydoc' with appropriate
    arguments.  The default behavior for HappyDoc is to read the files
    and directories specified as arguments and generate HTML output to
    the directory './doc'.  *Give it a whirl!*


General Information

  HappyDoc uses the Python parser to extract information from
  '__doc__' strings.  It also examines the signatures of functions and
  methods to include function prototypes in the output.  

  To use HappyDoc, simply run it against your source files or
  directory.  Use the '-h' or '--help' arguments to learn about the
  arguments and options accepted.  See below for more detailed
  directions about configuring your source for documentation purposes.

  Controlling the Output

    HappyDoc uses two different pluggable classes for controlling
    output.  A **formatter** class is responsible for producing the
    syntax of the actual output (e.g. HTML, XML, SGML, or PDF).  A
    **docset** class is responsible for controlling the formatter and
    managing the logical flow of the information (e.g., writing to
    multiple files or a single file, putting class documentation in a
    different file from the module, etc.).  Formatters and DocSets
    should be implemented so that any two can be combined.  It will
    not always be desirable to do this, but it should be possible.

  Documentation not in Doc-strings

    It is not always desirable to put all documentation in '__doc__'
    strings.  Sometimes, notably when working with
    "Zope":http://www.zope.org , special meaning is attached to the
    presence of '__doc__' strings.  For this reason, and to support
    existing code which might not have '__doc__' strings, HappyDoc
    will find and extract documentation in Python comments.  

    Comment documentation can contain all of the same formatting as
    '__doc__' strings.  The preceding comment marker will be stripped
    off and the lines will be assembled and treated as a block of text
    in the same way that the '__doc__' strings are treated.

    To use this feature, it is important to place the comments
    **before** the named object which they describe.  In this example::

      #
      # Class documentation goes here
      #
      class ClassWithNoDocStrings:
         "Using __doc__ strings overrides comment documentation."

         def method1(self, params):
             "This method uses a __doc__ string."
             pass

         #
         # Method2 does not use a __doc__ string.
         #
         def method2(self):
             pass

    The output would include the '__doc__' strings for the class and
    for 'method1'.  It would also make it appear that 'method2' had a
    '__doc__' string with the contents '"Method2 does not use a
    __doc__ string."'


Flexible Behavior

  HappyDoc provides several different abstractions to allow the same
  engine to process different types of inputs and convert them to
  different types of output.

  Docstring Converters

    *How does an author write documentation so that it will be marked
    up and look fancy?* This is a perennial question for
    "Python":http://www.python.org users, and seems to have introduced
    a roadblock into the development of more robust and useful
    documentation tools.  HappyDoc stands firmly on the fence and does
    not attempt to resolve the issue.  

    *Refer to the 'happydoclib.docset' package for more details.*

  Formatters

    Formatters are responsible for tranlating the higher level docset
    concepts into specific structures for an output type.  For
    example, the specific way a descriptive list might be rendered in
    HTML could vary between different HTML formatters.  The API for a
    formatter depends on the docset types which is is meant to
    support.

    *Refer to the 'happydoclib.formatter' package for more details.*


  DocSet types

    The docset, or *documentation set*, defines the structure of the
    collected documentation being generated.  All aspects of the
    structure are left up to the docset.  Whether to use multiple or a
    single file, a file or a database, and what specific metadata to
    include in the output is left up to the docset.  The docset drives
    the documentation generation using controls available from the
    formatter.

    *Refer to the 'happydoclib.docset' package for more details.*

Using HappyDoc

  Command Line Options

    HappyDoc uses standard 'getopt' style command line processing.
    For the complete reference of argument syntax, call the command
    line program with the '-h' or '--help' options.  The specific
    options supported are not documented here since they change over
    time.

  Parser, DocSet and Formatter Parameters

    Many DocSets and Formatters will take parameters.  The Parser also
    accepts global options using this method (see below for another
    way to control the parser).  To pass parameters past the command
    line argument processing of HappyDoc and in to the Parser, DocSet
    or Formatter being used, the variable is passed as an argument
    rather than option (no dashes) to HappyDoc.

    To allow the Parser, DocSets and Formatters to share variable
    namespace, the options passed are prefixed with a value indicating
    whether the variable is for the 'parser_', 'docset_' or
    'formatter_'.

    For example::

      % ./happydoc -d MySources/doc MySources \
		formatter_bgcolor1='#ffccaa'

    Or on Windows::

      > .\happydocwin.py -d MySources\doc MySources \
		formatter_bgcolor1="#ffccaa"

  File-specific Parser Configuration Values

    Parameters to the HappyDoc Parser can also be embedded within the
    first comment block of the module.  The parameter values
    recognized and their meanings are listed below.

    To provide file-specific parser configuration settings, any Python
    code can be embedded in the comments of the file.  For example::

      #!/usr/bin/env python
      #
      # HappyDoc:# These variables should be discovered.
      # HappyDoc:TestInt=1
      # HappyDoc:TestString="String"
      # HappyDoc:TestStringModule=string.strip(' this has spaces in front and back ')
      # HappyDoc:url=urlencode({'a':'A', 'b':'B'})
      # HappyDoc:docStringFormat='StructuredText'

    All lines beginning with the pattern "'# HappyDoc:'" will be
    concatenated (separated by newlines) and 'execed'.  The local
    namespace resulting from the execution of the code will be
    examined for variables of interest to the parser.  The incoming
    global namespace for the configuration code will have a few
    pre-populated names for convenience.

    *Refer to the happydoclib.parseinfo module for more details.*

  Input Types

    HappyDoc accepts 3 basic input types for documentation.  

    1. Any **file name** passed will be treated as a Python source file.
       The file will be parsed (but not imported) and the
       documentation text will be extracted from the resulting parse
       tree.

    2. Any **directory** passed will be interpreted to mean to document
       all of the files in that directory, so HappyDoc will recurse
       into the directory to find files.

    3. A **single, regular, text file** can be passed as the "package
       description file."  This file, defaulting to 'README.txt', will
       be interepreted as appropriate and included in the place of a
       '__doc__' string in the generated 'index.html' file.

Examples of HappyDoc Documentation

  Two example output documentation sets are available.

  - **HappyDoc**

    Of course HappyDoc is used to produce its own documentation.  The
    most current version is available on the 
    "HappyDoc home page":http://happydoc.sourceforge.net.

  - **Zope**

    Download a set of "Zope source
    documentation":http://www.zope.org/Documentation/Developer/ZopeSrcDocs
    based on a recent CVS checkout or most stable release of Zope on
    "Zope.org":http://www.zope.org.

    Browse the "Zope CVS Source":Zope-2-CVS-srcdocs documentation on
    the HappyDoc site.

Who else is using HappyDoc?

  - **Biopython** 

    The "Biopython project":http://www.biopython.org uses HappyDoc to
    generate the documentation for their
    "libraries":http://www.biopython.org/wiki/html/BioPython/BiopythonCode.html

  - **Numerical Python** 

    "Numerical Python":http://numpy.sourceforge.net adds a fast,
    compact multidimensional array language facility to Python.

  - **CDAT** 

    "Climate Data Analysis Tool":http://cdat.sourceforge.net is a
    Python-based, easily extendible system for accessing and analyzing
    climate data. It contains a generally useful system for scientific
    graphics.

Bugs

  Please use the "bug tracker":http://sourceforge.net/bugs/?group_id=9678 on the
  SourceForge project page for HappyDoc to report bugs and the 
  "feature tracker":http://sourceforge.net/tracker/?group_id=9678&atid=359678
  to request new features.

Support

  There are also "public forums":http://sourceforge.net/forum/?group_id=9678 
  and "mailing lists":http://sourceforge.net/mail/?group_id=9678 available on 
  SourceForge for questions regarding the use of HappyDoc, or plans for its
  future.