6.5 Inline Markup
The macros described in this section are used to mark just about anything interesting in the document text. They may be used in headings (though anything involving hyperlinks should be avoided there) as well as in the body text.
- Like \code, but also makes the font bold-face.
- The name of a C-language variable.
- The name of a C-language function. name should include the function name and the trailing parentheses.
- A character when discussing the character rather than a one-byte string value. The character will be typeset as with \samp.
- A title for a referenced publication. If url is specified, the title will be made into a hyperlink when formatted as HTML.
- A class name; a dotted name may be used.
- A short code fragment or literal constant value. Typically, it should not include any spaces since no quotation marks are added.
-
The name of a ``defined'' constant. This may be a C-language
#define
or a Python variable that is not intended to be changed.
- The name of a ``simple'' macro. Simple macros are macros which are used for code expansion, but which do not take arguments so cannot be described as functions. This is not to be used for simple constant definitions. Examples of it's use in the Python documentation include PyObject_HEAD and Py_BEGIN_ALLOW_THREADS.
-
The name of a C typedef or structure. For structures
defined without a typedef, use
\ctype{struct struct_tag}
to make it clear that the struct is required.
- Declare whatever is being described as being deprecated starting with release version. The text given as what to do should recommend something to use instead. It should be complete sentences. The entire deprecation notice will be presented as a separate paragraph; it should either precede or succeed the description of the deprecated feature.
- Mark the defining instance of term in the text. (No index entries are generated.)
- Produces a backslash. This is convenient in \code, \file, and similar macros, and the \alltt environment, and is only defined there. To create a backslash in ordinary text (such as the contents of the \citetitle macro), use the standard \textbackslash macro.
- An email address. Note that this is not hyperlinked in any of the possible output formats. The domain name portion of the address should be lower case.
- Emphasized text; this will be presented in an italic font.
- An environment variable. Index entries are generated.
- The name of an exception. A dotted name may be used.
- The name of a file or directory. In the PDF and PostScript outputs, single quotes and a font change are used to indicate the file name, but no quotes are used in the HTML output. Warning: The \file macro cannot be used in the content of a section title due to processing limitations.
- Like \file, but single quotes are never used. This can be used in conjunction with tables if a column will only contain file or directory names. Warning: The \filenq macro cannot be used in the content of a section title due to processing limitations.
- The name of a Python function; dotted names may be used.
- The symbol for mathematical infinity: ∞. Some Web browsers are not able to render the HTML representation of this symbol properly, but support is growing.
-
Mark a sequence of keystrokes. What form key sequence
takes may depend on platform- or application-specific
conventions. When there are no relevant conventions, the names
of modifier keys should be spelled out, to improve accessibility
for new users and non-native speakers. For example, an
xemacs key sequence may be marked like
\kbd{C-x C-f}
, but without reference to a specific application or platform, the same sequence should be marked as\kbd{Control-x Control-f}
.
- The name of a keyword in a programming language.
-
The name of an RFC 822-style mail header. This markup does
not imply that the header is being used in an email message, but
can be used to refer to any header of the same ``style.'' This
is also used for headers defined by the various MIME
specifications. The header name should be entered in the same
way it would normally be found in practice, with the
camel-casing conventions being preferred where there is more
than one common usage. The colon which follows the name of the
header should not be included.
For example:
\mailheader{Content-Type}
.
- The name of a make variable.
- A reference to a Unix manual page.
- The name of a data attribute of an object.
- The name of a method of an object. name should include the method name and the trailing parentheses. A dotted name may be used.
- The name of a MIME type, or a component of a MIME type (the major or minor portion, taken alone).
- The name of a module; a dotted name may be used. This should also be used for package names.
- The name of a Usenet newsgroup.
- An especially important bit of information about an API that a user should be aware of when using whatever bit of API the note pertains to. This should be the last thing in the paragraph as the end of the note is not visually marked in any way. The content of text should be written in complete sentences and include all appropriate punctuation.
- A reference to a Python Enhancement Proposal. This generates appropriate index entries. The text "PEP number" is generated; in the HTML output, this text is a hyperlink to an online copy of the specified PEP.
-
The symbol for indicating a value that may take a positive or
negative value of a specified magnitude, typically represented
by a plus sign placed over a minus sign. For example:
\plusminus 3%
.
- The name of an executable program. This may differ from the file name for the executable for some platforms. In particular, the .exe (or other) extension should be omitted for Windows programs.
- A command-line option to an executable program. Use this only for ``short'' options, and include the leading hyphen.
- A long command-line option to an executable program. This should only be used for long option names which will be prefixed by two hyphens; the hyphens should not be provided as part of option.
- Like \module, but create a hyperlink to the documentation for the named module. Note that the corresponding \declaremodule must be in the same document. If the \declaremodule defines a module key different from the module name, it must also be provided as key to the \refmodule macro.
- Mark a regular expression.
- A reference to an Internet Request for Comments. This generates appropriate index entries. The text "RFC number" is generated; in the HTML output, this text is a hyperlink to an online copy of the specified RFC.
- A short code sample, but possibly longer than would be given using \code. Since quotation marks are added, spaces are acceptable.
-
The ``short'' version number of the documented software, as
specified using the \setshortversion macro in the
preamble. For Python, the short version number for a release is
the first three characters of the
sys.version
value. For example, versions 2.0b1 and 2.0.1 both have a short version of 2.0. This may not apply for all packages; if \setshortversion is not used, this produces an empty expansion. See also the \version macro.
- Strongly emphasized text; this will be presented using a bold font.
- A hypertext link with a target specified by a URL, but for which the link text should not be the title of the resource. For resources being referenced by name, use the \citetitle macro. Not all formatted versions support arbitrary hypertext links. Note that many characters are special to LaTeX and this macro does not always do the right thing. In particular, the tilde character ("~") is mis-handled; encoding it as a hex-sequence does work, use "%7e" in place of the tilde character.
- A URL (or URN). The URL will be presented as text. In the HTML and PDF formatted versions, the URL will also be a hyperlink. This can be used when referring to external resources without specific titles; references to resources which have titles should be marked using the \citetitle macro. See the comments about special characters in the description of the \ulink macro for special considerations.
- The name of a variable or formal parameter in running text.
- The version number of the described software, as specified using \release in the preamble. See also the \shortversion macro.
- An important bit of information about an API that a user should be very aware of when using whatever bit of API the warning pertains to. This should be the last thing in the paragraph as the end of the warning is not visually marked in any way. The content of text should be written in complete sentences and include all appropriate punctuation. This differs from \note in that it is recommended over \note for information regarding security.
The following two macros are used to describe information that's associated with changes from one release to another. For features which are described by a single paragraph, these are typically added as separate source lines at the end of the paragraph. When adding these to features described by multiple paragraphs, they are usually collected in a single separate paragraph after the description. When both \versionadded and \versionchanged are used, \versionadded should come first; the versions should be listed in chronological order. Both of these should come before availability statements. The location should be selected so the explanation makes sense and may vary as needed.
- The version of Python which added the described feature to the library or C API. explanation should be a brief explanation of the change consisting of a capitalized sentence fragment; a period will be appended by the formatting process. When this applies to an entire module, it should be placed at the top of the module section before any prose.
- The version of Python in which the named feature was changed in some way (new parameters, changed side effects, etc.). explanation should be a brief explanation of the change consisting of a capitalized sentence fragment; a period will be appended by the formatting process. This should not generally be applied to modules.
See About this document... for information on suggesting changes.