diff --git a/Doc/library/asynchat.rst b/Doc/library/asynchat.rst
index b651c40..f870e12 100644
--- a/Doc/library/asynchat.rst
+++ b/Doc/library/asynchat.rst
@@ -9,72 +9,77 @@
 
 
 This module builds on the :mod:`asyncore` infrastructure, simplifying
-asynchronous clients and servers and making it easier to handle protocols whose
-elements are terminated by arbitrary strings, or are of variable length.
+asynchronous clients and servers and making it easier to handle protocols
+whose elements are terminated by arbitrary strings, or are of variable length.
 :mod:`asynchat` defines the abstract class :class:`async_chat` that you
 subclass, providing implementations of the :meth:`collect_incoming_data` and
 :meth:`found_terminator` methods. It uses the same asynchronous loop as
-:mod:`asyncore`, and the two types of channel, :class:`asyncore.dispatcher` and
-:class:`asynchat.async_chat`, can freely be mixed in the channel map. Typically
-an :class:`asyncore.dispatcher` server channel generates new
-:class:`asynchat.async_chat` channel objects as it receives incoming connection
-requests.
+:mod:`asyncore`, and the two types of channel, :class:`asyncore.dispatcher`
+and :class:`asynchat.async_chat`, can freely be mixed in the channel map.
+Typically an :class:`asyncore.dispatcher` server channel generates new
+:class:`asynchat.async_chat` channel objects as it receives incoming
+connection requests.
 
 
 .. class:: async_chat()
 
    This class is an abstract subclass of :class:`asyncore.dispatcher`. To make
    practical use of the code you must subclass :class:`async_chat`, providing
-   meaningful :meth:`collect_incoming_data` and :meth:`found_terminator` methods.
+   meaningful :meth:`collect_incoming_data` and :meth:`found_terminator`
+   methods.
    The :class:`asyncore.dispatcher` methods can be used, although not all make
    sense in a message/response context.
 
-   Like :class:`asyncore.dispatcher`, :class:`async_chat` defines a set of events
-   that are generated by an analysis of socket conditions after a :cfunc:`select`
-   call. Once the polling loop has been started the :class:`async_chat` object's
-   methods are called by the event-processing framework with no action on the part
-   of the programmer.
+   Like :class:`asyncore.dispatcher`, :class:`async_chat` defines a set of
+   events that are generated by an analysis of socket conditions after a
+   :cfunc:`select` call. Once the polling loop has been started the
+   :class:`async_chat` object's methods are called by the event-processing
+   framework with no action on the part of the programmer.
 
-   Unlike :class:`asyncore.dispatcher`, :class:`async_chat` allows you to define a
-   first-in-first-out queue (fifo) of *producers*. A producer need have only one
-   method, :meth:`more`, which should return data to be transmitted on the channel.
+   Unlike :class:`asyncore.dispatcher`, :class:`async_chat` allows you to
+   define a first-in-first-out queue (fifo) of *producers*. A producer need
+   have only one method, :meth:`more`, which should return data to be
+   transmitted on the channel.
    The producer indicates exhaustion (*i.e.* that it contains no more data) by
    having its :meth:`more` method return the empty string. At this point the
-   :class:`async_chat` object removes the producer from the fifo and starts using
-   the next producer, if any. When the producer fifo is empty the
+   :class:`async_chat` object removes the producer from the fifo and starts
+   using the next producer, if any. When the producer fifo is empty the
    :meth:`handle_write` method does nothing. You use the channel object's
-   :meth:`set_terminator` method to describe how to recognize the end of, or an
-   important breakpoint in, an incoming transmission from the remote endpoint.
+   :meth:`set_terminator` method to describe how to recognize the end of, or
+   an important breakpoint in, an incoming transmission from the remote
+   endpoint.
 
    To build a functioning :class:`async_chat` subclass your  input methods
-   :meth:`collect_incoming_data` and :meth:`found_terminator` must handle the data
-   that the channel receives asynchronously. The methods are described below.
+   :meth:`collect_incoming_data` and :meth:`found_terminator` must handle the
+   data that the channel receives asynchronously. The methods are described
+   below.
 
 
 .. method:: async_chat.close_when_done()
 
-   Pushes a ``None`` on to the producer fifo. When this producer is popped off the
-   fifo it causes the channel to be closed.
+   Pushes a ``None`` on to the producer fifo. When this producer is popped off
+   the fifo it causes the channel to be closed.
 
 
 .. method:: async_chat.collect_incoming_data(data)
 
-   Called with *data* holding an arbitrary amount of received data. The default
-   method, which must be overridden, raises a :exc:`NotImplementedError` exception.
+   Called with *data* holding an arbitrary amount of received data.  The
+   default method, which must be overridden, raises a
+   :exc:`NotImplementedError` exception.
 
 
 .. method:: async_chat.discard_buffers()
 
-   In emergencies this method will discard any data held in the input and/or output
-   buffers and the producer fifo.
+   In emergencies this method will discard any data held in the input and/or
+   output buffers and the producer fifo.
 
 
 .. method:: async_chat.found_terminator()
 
-   Called when the incoming data stream  matches the termination condition set by
-   :meth:`set_terminator`. The default method, which must be overridden, raises a
-   :exc:`NotImplementedError` exception. The buffered input data should be
-   available via an instance attribute.
+   Called when the incoming data stream  matches the termination condition set
+   by :meth:`set_terminator`. The default method, which must be overridden,
+   raises a :exc:`NotImplementedError` exception. The buffered input data
+   should be available via an instance attribute.
 
 
 .. method:: async_chat.get_terminator()
@@ -90,59 +95,59 @@
 
 .. method:: async_chat.handle_read()
 
-   Called when a read event fires on the channel's socket in the asynchronous loop.
-   The default method checks for the termination condition established by
-   :meth:`set_terminator`, which can be either the appearance of a particular
-   string in the input stream or the receipt of a particular number of characters.
-   When the terminator is found, :meth:`handle_read` calls the
-   :meth:`found_terminator` method after calling :meth:`collect_incoming_data` with
-   any data preceding the terminating condition.
+   Called when a read event fires on the channel's socket in the asynchronous
+   loop.  The default method checks for the termination condition established
+   by :meth:`set_terminator`, which can be either the appearance of a
+   particular string in the input stream or the receipt of a particular number
+   of characters.  When the terminator is found, :meth:`handle_read` calls the
+   :meth:`found_terminator` method after calling :meth:`collect_incoming_data`
+   with any data preceding the terminating condition.
 
 
 .. method:: async_chat.handle_write()
 
-   Called when the application may write data to the channel.   The default method
-   calls the :meth:`initiate_send` method, which in turn will call
-   :meth:`refill_buffer` to collect data from the producer fifo associated with the
-   channel.
+   Called when the application may write data to the channel.   The default
+   method calls the :meth:`initiate_send` method, which in turn will call
+   :meth:`refill_buffer` to collect data from the producer fifo associated
+   with the channel.
 
 
 .. method:: async_chat.push(data)
 
-   Creates a :class:`simple_producer` object (*see below*) containing the data and
-   pushes it on to the channel's ``producer_fifo`` to ensure its transmission. This
-   is all you need to do to have the channel write the data out to the network,
-   although it is possible to use your own producers in more complex schemes to
-   implement encryption and chunking, for example.
+   Creates a :class:`simple_producer` object (*see below*) containing the data
+   and pushes it on to the channel's ``producer_fifo`` to ensure its
+   transmission.  This is all you need to do to have the channel write the
+   data out to the network, although it is possible to use your own producers
+   in more complex schemes to implement encryption and chunking, for example.
 
 
 .. method:: async_chat.push_with_producer(producer)
 
-   Takes a producer object and adds it to the producer fifo associated with the
-   channel. When all currently-pushed producers have been exhausted the channel
-   will consume this producer's data by calling its :meth:`more` method and send
-   the data to the remote endpoint.
+   Takes a producer object and adds it to the producer fifo associated with
+   the channel.  When all currently-pushed producers have been exhausted the
+   channel will consume this producer's data by calling its :meth:`more`
+   method and send the data to the remote endpoint.
 
 
 .. method:: async_chat.readable()
 
-   Should return ``True`` for the channel to be included in the set of channels
-   tested by the :cfunc:`select` loop for readability.
+   Should return ``True`` for the channel to be included in the set of
+   channels tested by the :cfunc:`select` loop for readability.
 
 
 .. method:: async_chat.refill_buffer()
 
-   Refills the output buffer by calling the :meth:`more` method of the producer at
-   the head of the fifo. If it is exhausted then the producer is popped off the
-   fifo and the next producer is activated. If the current producer is, or becomes,
-   ``None`` then the channel is closed.
+   Refills the output buffer by calling the :meth:`more` method of the
+   producer at the head of the fifo.  If it is exhausted then the producer is
+   popped off the fifo and the next producer is activated.  If the current
+   producer is, or becomes, ``None`` then the channel is closed.
 
 
 .. method:: async_chat.set_terminator(term)
 
-   Sets the terminating condition to be recognised on the channel. ``term`` may be
-   any of three types of value, corresponding to three different ways to handle
-   incoming protocol data.
+   Sets the terminating condition to be recognized on the channel.  ``term``
+   may be any of three types of value, corresponding to three different ways
+   to handle incoming protocol data.
 
    +-----------+---------------------------------------------+
    | term      | Description                                 |
@@ -158,8 +163,8 @@
    |           | forever                                     |
    +-----------+---------------------------------------------+
 
-   Note that any data following the terminator will be available for reading by the
-   channel after :meth:`found_terminator` is called.
+   Note that any data following the terminator will be available for reading
+   by the channel after :meth:`found_terminator` is called.
 
 
 .. method:: async_chat.writable()
@@ -174,29 +179,29 @@
 
 .. class:: simple_producer(data[, buffer_size=512])
 
-   A :class:`simple_producer` takes a chunk of data and an optional buffer size.
-   Repeated calls to its :meth:`more` method yield successive chunks of the data no
-   larger than *buffer_size*.
+   A :class:`simple_producer` takes a chunk of data and an optional buffer
+   size.  Repeated calls to its :meth:`more` method yield successive chunks of
+   the data no larger than *buffer_size*.
 
 
 .. method:: simple_producer.more()
 
-   Produces the next chunk of information from the producer, or returns the empty
-   string.
+   Produces the next chunk of information from the producer, or returns the
+   empty string.
 
 
 .. class:: fifo([list=None])
 
-   Each channel maintains a :class:`fifo` holding data which has been pushed by the
-   application but not yet popped for writing to the channel. A :class:`fifo` is a
-   list used to hold data and/or producers until they are required. If the *list*
-   argument is provided then it should contain producers or data items to be
-   written to the channel.
+   Each channel maintains a :class:`fifo` holding data which has been pushed
+   by the application but not yet popped for writing to the channel.  A
+   :class:`fifo` is a list used to hold data and/or producers until they are
+   required.  If the *list* argument is provided then it should contain
+   producers or data items to be written to the channel.
 
 
 .. method:: fifo.is_empty()
 
-   Returns ``True`` iff the fifo is empty.
+   Returns ``True`` if and only if the fifo is empty.
 
 
 .. method:: fifo.first()
@@ -206,14 +211,14 @@
 
 .. method:: fifo.push(data)
 
-   Adds the given data (which may be a string or a producer object) to the producer
-   fifo.
+   Adds the given data (which may be a string or a producer object) to the
+   producer fifo.
 
 
 .. method:: fifo.pop()
 
-   If the fifo is not empty, returns ``True, first()``, deleting the popped item.
-   Returns ``False, None`` for an empty fifo.
+   If the fifo is not empty, returns ``True, first()``, deleting the popped
+   item.  Returns ``False, None`` for an empty fifo.
 
 The :mod:`asynchat` module also defines one utility function, which may be of
 use in network and textual analysis operations.
@@ -221,8 +226,8 @@
 
 .. function:: find_prefix_at_end(haystack, needle)
 
-   Returns ``True`` if string *haystack* ends with any non-empty prefix of string
-   *needle*.
+   Returns ``True`` if string *haystack* ends with any non-empty prefix of
+   string *needle*.
 
 
 .. _asynchat-example:
@@ -231,19 +236,20 @@
 ----------------
 
 The following partial example shows how HTTP requests can be read with
-:class:`async_chat`. A web server might create an :class:`http_request_handler`
-object for each incoming client connection. Notice that initially the channel
-terminator is set to match the blank line at the end of the HTTP headers, and a
-flag indicates that the headers are being read.
+:class:`async_chat`.  A web server might create an
+:class:`http_request_handler` object for each incoming client connection.
+Notice that initially the channel terminator is set to match the blank line at
+the end of the HTTP headers, and a flag indicates that the headers are being
+read.
 
-Once the headers have been read, if the request is of type POST (indicating that
-further data are present in the input stream) then the ``Content-Length:``
-header is used to set a numeric terminator to read the right amount of data from
-the channel.
+Once the headers have been read, if the request is of type POST (indicating
+that further data are present in the input stream) then the
+``Content-Length:`` header is used to set a numeric terminator to read the
+right amount of data from the channel.
 
 The :meth:`handle_request` method is called once all relevant input has been
-marshalled, after setting the channel terminator to ``None`` to ensure that any
-extraneous data sent by the web client are ignored. ::
+marshalled, after setting the channel terminator to ``None`` to ensure that
+any extraneous data sent by the web client are ignored. ::
 
    class http_request_handler(asynchat.async_chat):
 
@@ -281,4 +287,3 @@
                self.handling = True
                self.ibuffer = []
                self.handle_request()
-
diff --git a/Doc/library/asyncore.rst b/Doc/library/asyncore.rst
index 7f80dd3..f48134b 100644
--- a/Doc/library/asyncore.rst
+++ b/Doc/library/asyncore.rst
@@ -3,7 +3,8 @@
 ===============================================
 
 .. module:: asyncore
-   :synopsis: A base class for developing asynchronous socket  handling services.
+   :synopsis: A base class for developing asynchronous socket handling
+              services.
 .. moduleauthor:: Sam Rushing <rushing@nightmare.com>
 .. sectionauthor:: Christopher Petrilli <petrilli@amber.org>
 .. sectionauthor:: Steve Holden <sholden@holdenweb.com>
@@ -16,59 +17,62 @@
 
 There are only two ways to have a program on a single processor do  "more than
 one thing at a time." Multi-threaded programming is the  simplest and most
-popular way to do it, but there is another very  different technique, that lets
+popular way to do it, but there is another very different technique, that lets
 you have nearly all the advantages of  multi-threading, without actually using
 multiple threads.  It's really  only practical if your program is largely I/O
-bound.  If your program  is processor bound, then pre-emptive scheduled threads
-are probably what  you really need. Network servers are rarely processor bound,
-however.
+bound.  If your program is processor bound, then pre-emptive scheduled threads
+are probably what you really need.  Network servers are rarely processor
+bound, however.
 
 If your operating system supports the :cfunc:`select` system call in its I/O
 library (and nearly all do), then you can use it to juggle multiple
-communication channels at once; doing other work while your I/O is taking place
-in the "background."  Although this strategy can seem strange and complex,
-especially at first, it is in many ways easier to understand and control than
-multi-threaded programming.  The :mod:`asyncore` module solves many of the
-difficult problems for you, making the task of building sophisticated
-high-performance network servers and clients a snap. For "conversational"
-applications and protocols the companion :mod:`asynchat` module is invaluable.
+communication channels at once; doing other work while your I/O is taking
+place in the "background."  Although this strategy can seem strange and
+complex, especially at first, it is in many ways easier to understand and
+control than multi-threaded programming.  The :mod:`asyncore` module solves
+many of the difficult problems for you, making the task of building
+sophisticated high-performance network servers and clients a snap.  For
+"conversational" applications and protocols the companion :mod:`asynchat`
+module is invaluable.
 
-The basic idea behind both modules is to create one or more network *channels*,
-instances of class :class:`asyncore.dispatcher` and
-:class:`asynchat.async_chat`. Creating the channels adds them to a global map,
-used by the :func:`loop` function if you do not provide it with your own *map*.
+The basic idea behind both modules is to create one or more network
+*channels*, instances of class :class:`asyncore.dispatcher` and
+:class:`asynchat.async_chat`.  Creating the channels adds them to a global
+map, used by the :func:`loop` function if you do not provide it with your own
+*map*.
 
 Once the initial channel(s) is(are) created, calling the :func:`loop` function
-activates channel service, which continues until the last channel (including any
-that have been added to the map during asynchronous service) is closed.
+activates channel service, which continues until the last channel (including
+any that have been added to the map during asynchronous service) is closed.
 
 
 .. function:: loop([timeout[, use_poll[, map[,count]]]])
 
-   Enter a polling loop that terminates after count passes or all open channels
-   have been closed.  All arguments are optional.  The *count* parameter defaults
-   to None, resulting in the loop terminating only when all channels have been
-   closed.  The *timeout* argument sets the timeout parameter for the appropriate
-   :func:`select` or :func:`poll` call, measured in seconds; the default is 30
-   seconds. The *use_poll* parameter, if true, indicates that :func:`poll` should
-   be used in preference to :func:`select` (the default is ``False``).
+   Enter a polling loop that terminates after count passes or all open
+   channels have been closed.  All arguments are optional.  The *count*
+   parameter defaults to None, resulting in the loop terminating only when all
+   channels have been closed.  The *timeout* argument sets the timeout
+   parameter for the appropriate :func:`select` or :func:`poll` call, measured
+   in seconds; the default is 30 seconds.  The *use_poll* parameter, if true,
+   indicates that :func:`poll` should be used in preference to :func:`select`
+   (the default is ``False``).
 
-   The *map* parameter is a dictionary whose items are the channels to watch.  As
-   channels are closed they are deleted from their map.  If *map* is omitted, a
-   global map is used. Channels (instances of :class:`asyncore.dispatcher`,
-   :class:`asynchat.async_chat` and subclasses thereof) can freely be mixed in the
-   map.
+   The *map* parameter is a dictionary whose items are the channels to watch.
+   As channels are closed they are deleted from their map.  If *map* is
+   omitted, a global map is used. Channels (instances of
+   :class:`asyncore.dispatcher`, :class:`asynchat.async_chat` and subclasses
+   thereof) can freely be mixed in the map.
 
 
 .. class:: dispatcher()
 
    The :class:`dispatcher` class is a thin wrapper around a low-level socket
-   object. To make it more useful, it has a few methods for event-handling  which
-   are called from the asynchronous loop.   Otherwise, it can be treated as a
-   normal non-blocking socket object.
+   object. To make it more useful, it has a few methods for event-handling
+   which are called from the asynchronous loop.   Otherwise, it can be treated
+   as a normal non-blocking socket object.
 
-   Two class attributes can be modified, to improve performance, or possibly even
-   to conserve memory.
+   Two class attributes can be modified, to improve performance, or possibly
+   even to conserve memory.
 
 
    .. data:: ac_in_buffer_size
@@ -80,12 +84,13 @@
 
       The asynchronous output buffer size (default ``4096``).
 
-   The firing of low-level events at certain times or in certain connection states
-   tells the asynchronous loop that certain higher-level events have taken place.
-   For example, if we have asked for a socket to connect to another host, we know
-   that the connection has been made when the socket becomes writable for the first
-   time (at this point you know that you may write to it with the expectation of
-   success). The implied higher-level events are:
+   The firing of low-level events at certain times or in certain connection
+   states tells the asynchronous loop that certain higher-level events have
+   taken place.  For example, if we have asked for a socket to connect to
+   another host, we know that the connection has been made when the socket
+   becomes writable for the first time (at this point you know that you may
+   write to it with the expectation of success).  The implied higher-level
+   events are:
 
    +----------------------+----------------------------------------+
    | Event                | Description                            |
@@ -101,11 +106,11 @@
 
    During asynchronous processing, each mapped channel's :meth:`readable` and
    :meth:`writable` methods are used to determine whether the channel's socket
-   should be added to the list of channels :cfunc:`select`\ ed or :cfunc:`poll`\ ed
-   for read and write events.
+   should be added to the list of channels :cfunc:`select`\ ed or
+   :cfunc:`poll`\ ed for read and write events.
 
-Thus, the set of channel events is larger than the basic socket events. The full
-set of methods that can be overridden in your subclass follows:
+Thus, the set of channel events is larger than the basic socket events.  The
+full set of methods that can be overridden in your subclass follows:
 
 
 .. method:: dispatcher.handle_read()
@@ -116,9 +121,9 @@
 
 .. method:: dispatcher.handle_write()
 
-   Called when the asynchronous loop detects that a writable socket can be written.
-   Often this method will implement the necessary buffering for  performance.  For
-   example::
+   Called when the asynchronous loop detects that a writable socket can be
+   written.  Often this method will implement the necessary buffering for
+   performance.  For example::
 
       def handle_write(self):
           sent = self.send(self.buffer)
@@ -127,15 +132,15 @@
 
 .. method:: dispatcher.handle_expt()
 
-   Called when there is out of band (OOB) data for a socket  connection.  This will
-   almost never happen, as OOB is  tenuously supported and rarely used.
+   Called when there is out of band (OOB) data for a socket connection.  This
+   will almost never happen, as OOB is tenuously supported and rarely used.
 
 
 .. method:: dispatcher.handle_connect()
 
-   Called when the active opener's socket actually makes a connection. Might send a
-   "welcome" banner, or initiate a protocol negotiation with the remote endpoint,
-   for example.
+   Called when the active opener's socket actually makes a connection.  Might
+   send a "welcome" banner, or initiate a protocol negotiation with the remote
+   endpoint, for example.
 
 
 .. method:: dispatcher.handle_close()
@@ -152,40 +157,40 @@
 .. method:: dispatcher.handle_accept()
 
    Called on listening channels (passive openers) when a   connection can be
-   established with a new remote endpoint that has issued a :meth:`connect` call
-   for the local endpoint.
+   established with a new remote endpoint that has issued a :meth:`connect`
+   call for the local endpoint.
 
 
 .. method:: dispatcher.readable()
 
-   Called each time around the asynchronous loop to determine whether a channel's
-   socket should be added to the list on which read events can occur.  The default
-   method simply returns ``True``,  indicating that by default, all channels will
-   be interested in read events.
+   Called each time around the asynchronous loop to determine whether a
+   channel's socket should be added to the list on which read events can
+   occur.  The default method simply returns ``True``, indicating that by
+   default, all channels will be interested in read events.
 
 
 .. method:: dispatcher.writable()
 
-   Called each time around the asynchronous loop to determine whether a channel's
-   socket should be added to the list on which write events can occur.  The default
-   method simply returns ``True``,  indicating that by default, all channels will
-   be interested in write events.
+   Called each time around the asynchronous loop to determine whether a
+   channel's socket should be added to the list on which write events can
+   occur.  The default method simply returns ``True``, indicating that by
+   default, all channels will be interested in write events.
 
-In addition, each channel delegates or extends many of the socket methods. Most
-of these are nearly identical to their socket partners.
+In addition, each channel delegates or extends many of the socket methods.
+Most of these are nearly identical to their socket partners.
 
 
 .. method:: dispatcher.create_socket(family, type)
 
-   This is identical to the creation of a normal socket, and  will use the same
-   options for creation.  Refer to the :mod:`socket` documentation for information
-   on creating sockets.
+   This is identical to the creation of a normal socket, and will use the same
+   options for creation.  Refer to the :mod:`socket` documentation for
+   information on creating sockets.
 
 
 .. method:: dispatcher.connect(address)
 
-   As with the normal socket object, *address* is a  tuple with the first element
-   the host to connect to, and the  second the port number.
+   As with the normal socket object, *address* is a tuple with the first
+   element the host to connect to, and the second the port number.
 
 
 .. method:: dispatcher.send(data)
@@ -195,38 +200,41 @@
 
 .. method:: dispatcher.recv(buffer_size)
 
-   Read at most *buffer_size* bytes from the socket's remote end-point. An empty
-   string implies that the channel has been closed from the other end.
+   Read at most *buffer_size* bytes from the socket's remote end-point.
+   An empty string implies that the channel has been closed from the other
+   end.
 
 
 .. method:: dispatcher.listen(backlog)
 
-   Listen for connections made to the socket.  The *backlog* argument specifies the
-   maximum number of queued connections and should be at least 1; the maximum value
-   is system-dependent (usually 5).
+   Listen for connections made to the socket.  The *backlog* argument
+   specifies the maximum number of queued connections and should be at least
+   1; the maximum value is system-dependent (usually 5).
 
 
 .. method:: dispatcher.bind(address)
 
    Bind the socket to *address*.  The socket must not already be bound.  (The
-   format of *address* depends on the address family --- see above.)  To mark the
-   socket as re-usable (setting the :const:`SO_REUSEADDR` option), call the
-   :class:`dispatcher` object's :meth:`set_reuse_addr` method.
+   format of *address* depends on the address family --- see above.)  To mark
+   the socket as re-usable (setting the :const:`SO_REUSEADDR` option), call
+   the :class:`dispatcher` object's :meth:`set_reuse_addr` method.
 
 
 .. method:: dispatcher.accept()
 
-   Accept a connection.  The socket must be bound to an address and listening for
-   connections.  The return value is a pair ``(conn, address)`` where *conn* is a
-   *new* socket object usable to send and receive data on the connection, and
-   *address* is the address bound to the socket on the other end of the connection.
+   Accept a connection.  The socket must be bound to an address and listening
+   for connections.  The return value is a pair ``(conn, address)`` where
+   *conn* is a *new* socket object usable to send and receive data on the
+   connection, and *address* is the address bound to the socket on the other
+   end of the connection.
 
 
 .. method:: dispatcher.close()
 
-   Close the socket.  All future operations on the socket object will fail.  The
-   remote end-point will receive no more data (after queued data is flushed).
-   Sockets are automatically closed when they are garbage-collected.
+   Close the socket.  All future operations on the socket object will fail.
+   The remote end-point will receive no more data (after queued data is
+   flushed).  Sockets are automatically closed when they are
+   garbage-collected.
 
 
 .. _asyncore-example:
@@ -266,4 +274,3 @@
    c = http_client('www.python.org', '/')
 
    asyncore.loop()
-