Provided by: python-epydoc_3.0.1+dfsg-20_all bug

NAME

       epydocgui - graphical interface to epydoc

SYNOPSIS

       epydocgui [project.prj | modules...]

       epydoc -h

       epydoc -V

DESCRIPTION

       epydocgui is a graphical interface to epydoc, which generates API documentation for Python
       modules and packages, based on their docstrings.  A  lightweight  markup  language  called
       epytext  can  be  used to format docstrings, and to add information about specific fields,
       such as parameters and instance variables.

       The API documentation produced by  epydocgui  consists  of  a  set  of  HTML  files.   Two
       subdirectories  are  created  for  the  public  and  private  documentation.   Within each
       subdirectories, every class and module is documented in its own file.  An  index  file,  a
       trees  file,  and  a  help file are also created.  If you select the frames option, then a
       frames-based table of contents is also produced.

OPTIONS

       project.prj
              The name of a project file that was saved with epydocgui.  Project files  record  a
              list  of  related  modules,  and  the  options  that should be used to generate the
              documentation for those modules.

       modules...
              The list of the modules that should be documented.  Modules can be specified  using
              module names (such as os.path), filenames (such as epydoc/epytext.py), or directory
              names (such as epydoc/).  Directory names specify packages,  and  are  expanded  to
              include all sub-modules and sub-packages.

       -h, --help, --usage, -?
              Display a usage message.

       -V, --version
              Print the version of Epydoc.

HTML FILES

       The API documentation produced by epydoc consists of the following files:

           index.html
                  The  standard  entry  point  for  the documentation.  Normally, index.html is a
                  frame index file, which defines three frames: two frames on the  left  side  of
                  the  browser  contain a table of contents, and the main frame on the right side
                  of the window contains documentation pages.  But if the --no-frames  option  is
                  used, then index.html will redirect the user to the project's top page.

           m-module.html
                  The  API documentation for a module.  module is the complete dotted name of the
                  module, such as sys or epydoc.epytext.

           c-class.html
                  The API documentation for a class, exception,  or  type.   c  is  the  complete
                  dotted name of the class, such as epydoc.epytext.Token or array.ArrayType.

           trees.html
                  The module and class hierarchies.

           indices.html
                  The term  and identifier indices.

           help.html
                  The  help page for the project.  This page explains how to use and navigate the
                  webpage produced by epydoc.

           toc.html
                  The top-level table of contents page.  This page is displayed in the upper-left
                  frame,  and  provides  links  to  toc-everything.html and the toc-m-module.html
                  files.  toc.html is not generated if the --no-frames option is used.

           toc-everything.html
                  The table of contents for the entire project.  This page is  displayed  in  the
                  lower-left frame, and provides links to every class, type, exception, function,
                  and variable defined by the project.  toc-everything.html is not  generated  if
                  the --no-frames option is used.

           toc-m-module.html
                  The  table  of contents for a module.  This page is displayed in the lower-left
                  frame, and provides links  to  every  class,  type,  exception,  function,  and
                  variable  defined  by  the  module.   module is the complete dotted name of the
                  module, such as sys or epydoc.epytext.  toc-m-module.html is not  generated  if
                  the --no-frames option is used.

           epydoc.css
                  The CSS stylesheet used to display all HTML pages.

       By default, epydoc creates two subdirectories in the output directory: public and private.
       Each directory contains all of the files specified above.  But if the --no-private  option
       is  used,  then  no  subdirectories  are  created, and the public documentation is written
       directly to the output directory.  ivided into five  categories:  import  errors;  epytext
       errors;  epytext  warnings;  field  warnings;  and  inspection  errors.   Whenever  epydoc
       encounters an error, it issues a warning message that describes the error, and attempts to
       continue generating documentation.

       Import errors indicate that epydoc was unable to import a module.  Import errors typically
       prevent epydoc from generating documentation for  the  module  in  question.   Epydoc  can
       generate the following import errors:

           Bad module name module
                  Epydoc  attempted to import module, but module is not a valid name for a Python
                  module.

           Could not find a UID for link-target
                  Epydoc was unable to find the object referred to by an inline link construction
                  (L{...}).  This is usually caused by a typo in the link.

           Could not import module
                  Epydoc  attempted  to import module, but it failed.  This typically occurs when
                  module raises an exception.

           file does not exist
                  Epydoc attempted to import the module contained in  file,  but  file  does  not
                  exist.

       Epytext  errors are caused by epytext docstrings that contain invalid markup.  Whenever an
       epytext error is detected, the docstring in question is treated as a plaintext  docstring.
       Epydoc can generate the following epytext errors:

           Bad link target.
                  The  target  specified  for  an  inline link construction (L{...}) is not well-
                  formed.  Link targets must be valid python identifiers.

           Bad uri target.
                  The target specified for an inline  uri  construction  (U{...})  is  not  well-
                  formed.   This  typically  occurs  if  inline  markup  is nested inside the URI
                  target.

           Fields must be at the top level.
                  The list of fields (@param, etc.)  is contained by some other  block  structure
                  (such as a list or a section).

           Fields must be the final elements.
                  The list of fields (@param, etc.)  is not at the end of a docstring.

           Headings must occur at top level.
                  The heading is contianed in some other block structure (such as a list).

           Improper doctest block indentation.
                  The doctest block dedents past the indentation of its initial prompt line.

           Improper heading indentation.
                  The  heading  for  a  section  is  not  left-aligned with the paragraphs in the
                  section that contains it.

           Improper paragraph indentation.
                  The paragraphs within a block  are  not  left-aligned.   This  error  is  often
                  generated when plaintext docstrings are parsed using epytext.

           Invalid escape.
                  An  unknown  escape  sequence  was  used  with  the  inline escape construction
                  (E{...}).

           Lists must be indented.
                  An unindented line immediately following a paragraph starts with a list bullet.
                  Epydoc  is  not sure whether you meant to start a new list item, or meant for a
                  paragraph to include a word that looks like a  bullet.   If  you  intended  the
                  former,  then  indent  the  list.   If you intended the latter, then change the
                  word-wrapping of the paragraph, or escape the first character of the word  that
                  looks like a bullet.

           Unbalanced '{'.
                  The  docstring  contains  unbalanced  braces.  Epytext requires that all braces
                  must be balanced.  To  include  a  single  unbalanced  brace,  use  the  escape
                  sequences E{lb} (left brace) and E{rb} (right brace).

           Unbalanced '}'.
                  The  docstring  contains  unbalanced  braces.  Epytext requires that all braces
                  must be balanced.  To  include  a  single  unbalanced  brace,  use  the  escape
                  sequences E{lb} (left brace) and E{rb} (right brace).

           Unknown inline markup tag.
                  An unknown tag was used with the inline markup construction ( x{...} ).

           Wrong underline character for heading.
                  The  underline  character  used  for  this section heading does not indicate an
                  appopriate section level.  The  "="  character  should  be  used  to  underline
                  sections; "-" for subsections; and "~" for subsubsections.

       Epytext  warnings are caused by epytext docstrings that contain questionable or suspicious
       markup.  Epytext warnings do not prevent the docstring  in  question  from  being  parsed.
       Epydoc can generate the following epytext warnings:

           Possible mal-formatted field item.
                  Epytext  detected  a  line  that  looks like a field item, but is not correctly
                  formatted.  This typically occurs when the trailing colon (":") is not included
                  in the field tag.

           Possible heading typo.
                  Epytext  detected  a pair of lines that looks like a heading, but the number of
                  underline characters does not match the number of characters  in  the  heading.
                  The  number  of characters in these two lines must match exactly for them to be
                  considered a heading.

       Field warnings are caused by epytext docstrings containing invalid fields.   The  contents
       of  the  invalid  field  are  generally  ignored.  Epydoc can generate the following field
       warnings:

           @param for unknown parameter param.
                  A @param field was used to specify  the  type  for  a  parameter  that  is  not
                  included  in  the  function's signature.  This is typically caused by a typo in
                  the parameter name.

           tag did not expect an argument.
                  The field tag tag was used with an argument, but it does not take one.

           tag expected an argument.
                  The field tag tag was used without an argument, but it requires one.

           @type for unknown parameter param.
                  A @type field was used to specify the type for a parameter that is not included
                  in  the  function's  signature.   This  is  typically  caused  by a typo in the
                  parameter name.

           @type for unknown variable var.
                  A @type field was used to specify  the  type  for  a  variable,  but  no  other
                  information is known about the variable.  This is typically caused by a typo in
                  the variable name.

           Unknown field tag tag.
                  A docstring contains a field with the unknown tag tag.

           Redefinition of field.
                  Multiple field tags define the value of field in the same docstring, but  field
                  can only take a single value.

       Inspection  errors are generated if epydoc encounters problems while attempting to inspect
       the properties of a documented object.  Most of inspection errors do  not  prevent  epydoc
       from  documenting  the  object  in question.  Epydoc can generate the following inspection
       errors:

           The parameters of inhmethod do not match basemethod.
                  The parameters of the undocumented method inhmethod do not match the parameters
                  of  the base class method basemethod that it overrides.  As a result, inhmethod
                  does  not  inherit  documentation  from  basemethod.   If  the  difference   in
                  parameters  is  intentional,  then  you  can  eliminate the warning by adding a
                  (possibly empty) docstring to inhmethod.

           Docmap cannot add a type
                  Epydoc attempted to document an object with an unknown  type.   This  error  is
                  typically  generated  by  packages  and  modules  that  manipulate  the  import
                  mechanism, such that importing a module produces some other type of object.

           UID conflict detected: uid
                  Two different objects were assigned the same unique identifier by epydoc.  This
                  can  cause  epydoc  to  substitute  the  documentation  of  one object with the
                  documentation of another object that is assigned the  same  unique  identifier.
                  However, this will usually only cause problems if the two objects with the same
                  unique identifiers  are  both  modules  or  classes,  in  which  case  the  API
                  documentation page for one object will overwrite the API documentation page for
                  the other object.

           object appears in multiple builtin modules
                  While attempting to determine which module defines the builtin  object  object,
                  epydoc  encountered  multiple  candidates,  and  was  unable  to  decide  which
                  candidate was correct.  In this case,  epydoc  arbitrarily  chooses  the  first
                  candidate that it finds.

           object appears in multiple .py modules
                  While  attempting  to determine which module defines the builtin object object,
                  epydoc  encountered  multiple  candidates,  and  was  unable  to  decide  which
                  candidate  was  correct.   In  this  case, epydoc arbitrarily chooses the first
                  candidate that it finds.

           object appears in multiple .so modules
                  While attempting to determine which module defines the builtin  object  object,
                  epydoc  encountered  multiple  candidates,  and  was  unable  to  decide  which
                  candidate was correct.  In this case,  epydoc  arbitrarily  chooses  the  first
                  candidate that it finds.

           Could not find a module for object
                  Epydoc  was  unable  to  determine which module defines object.  If object is a
                  function, then this will prevent epydoc from generating any  documentation  for
                  object,  since  it  does  not  know  what  page  to  put  the documentation on.
                  Otherwise, this will prevent the documentation for object from including a link
                  to its containing module.

AUTHOR

       Epydoc  was written by Edward Loper.  This man page was originally written by Moshe Zadka,
       and is currently maintained by Edward Loper.  Debian-specific modifications were  made  by
       Kenneth J. Pronovici.

BUGS

       Report bugs to <edloper@gradient.cis.upenn.edu>.

SEE ALSO

       epydoc(1)

       The epydoc webpage
              <http://epydoc.sourceforge.net>

       The epytext markup language manual
              <http://epydoc.sourceforge.net/epytext.html>

                                                                                     EPYDOCGUI(1)