Merged revisions 71572 via svnmerge from

svn+ssh://pythondev@svn.python.org/python/trunk

........
  r71572 | georg.brandl | 2009-04-13 15:13:25 +0200 (Mo, 13 Apr 2009) | 1 line

  #5745: more linking for identifiers in email docs.
........

1 files changed, 15 insertions, 14 deletions

diff --git a/Doc/library/email.parser.rst b/Doc/library/email.parser.rst
index 43f0238..ec2e71b 100644
--- a/Doc/library/email.parser.rst
+++ b/Doc/library/email.parser.rst
@@ -6,18 +6,18 @@
 
 
 Message object structures can be created in one of two ways: they can be created
-from whole cloth by instantiating :class:`Message` objects and stringing them
-together via :meth:`attach` and :meth:`set_payload` calls, or they can be
-created by parsing a flat text representation of the email message.
+from whole cloth by instantiating :class:`~email.message.Message` objects and
+stringing them together via :meth:`attach` and :meth:`set_payload` calls, or they
+can be created by parsing a flat text representation of the email message.
 
 The :mod:`email` package provides a standard parser that understands most email
 document structures, including MIME documents.  You can pass the parser a string
-or a file object, and the parser will return to you the root :class:`Message`
-instance of the object structure.  For simple, non-MIME messages the payload of
-this root object will likely be a string containing the text of the message.
-For MIME messages, the root object will return ``True`` from its
-:meth:`is_multipart` method, and the subparts can be accessed via the
-:meth:`get_payload` and :meth:`walk` methods.
+or a file object, and the parser will return to you the root
+:class:`~email.message.Message` instance of the object structure.  For simple,
+non-MIME messages the payload of this root object will likely be a string
+containing the text of the message.  For MIME messages, the root object will
+return ``True`` from its :meth:`is_multipart` method, and the subparts can be
+accessed via the :meth:`get_payload` and :meth:`walk` methods.
 
 There are actually two parser interfaces available for use, the classic
 :class:`Parser` API and the incremental :class:`FeedParser` API.  The classic
@@ -31,8 +31,8 @@ incrementally, and only returns the root object when you close the parser [#]_.
 Note that the parser can be extended in limited ways, and of course you can
 implement your own parser completely from scratch.  There is no magical
 connection between the :mod:`email` package's bundled parser and the
-:class:`Message` class, so your custom parser can create message object trees
-any way it finds necessary.
+:class:`~email.message.Message` class, so your custom parser can create message
+object trees any way it finds necessary.
 
 
 FeedParser API
@@ -101,8 +101,8 @@ class.
    The constructor for the :class:`Parser` class takes an optional argument
    *_class*.  This must be a callable factory (such as a function or a class), and
    it is used whenever a sub-message object needs to be created.  It defaults to
-   :class:`Message` (see :mod:`email.message`).  The factory will be called without
-   arguments.
+   :class:`~email.message.Message` (see :mod:`email.message`).  The factory will
+   be called without arguments.
 
    The optional *strict* flag is ignored.
 
@@ -179,7 +179,8 @@ Here are some notes on the parsing semantics:
 * All :mimetype:`multipart` type messages will be parsed as a container message
   object with a list of sub-message objects for their payload.  The outer
   container message will return ``True`` for :meth:`is_multipart` and their
-  :meth:`get_payload` method will return the list of :class:`Message` subparts.
+  :meth:`get_payload` method will return the list of :class:`~email.message.Message`
+  subparts.
 
 * Most messages with a content type of :mimetype:`message/\*` (e.g.
   :mimetype:`message/delivery-status` and :mimetype:`message/rfc822`) will also be