# HG changeset patch
# Parent 07613ea46dbc904d9518faa014bf20d76d655b48

diff --git a/Doc/howto/sockets.rst b/Doc/howto/sockets.rst
--- a/Doc/howto/sockets.rst
+++ b/Doc/howto/sockets.rst
@@ -66,10 +66,11 @@
    # - the normal http port
    s.connect(("www.mcmillan-inc.com", 80))
 
-When the ``connect`` completes, the socket ``s`` can now be used to send in a
-request for the text of this page. The same socket will read the reply, and then
-be destroyed. That's right - destroyed. Client sockets are normally only used
-for one exchange (or a small set of sequential exchanges).
+When the ``connect`` completes, the socket ``s`` can be used to send
+in a request for the text of the page. The same socket will read the
+reply, and then be destroyed. That's right, destroyed. Client sockets
+are normally only used for one exchange (or a small set of sequential
+exchanges).
 
 What happens in the web server is a bit more complex. First, the web server
 creates a "server socket". ::
@@ -96,7 +97,7 @@
 queue up as many as 5 connect requests (the normal max) before refusing outside
 connections. If the rest of the code is written properly, that should be plenty.
 
-OK, now we have a "server" socket, listening on port 80. Now we enter the
+Now that we have a "server" socket, listening on port 80, we can enter the
 mainloop of the web server::
 
    while True:
@@ -145,7 +146,7 @@
 
 Now there are two sets of verbs to use for communication. You can use ``send``
 and ``recv``, or you can transform your client socket into a file-like beast and
-use ``read`` and ``write``. The latter is the way Java presents their sockets.
+use ``read`` and ``write``. The latter is the way Java presents its sockets.
 I'm not going to talk about it here, except to warn you that you need to use
 ``flush`` on sockets. These are buffered "files", and a common mistake is to
 ``write`` something, and then ``read`` for a reply. Without a ``flush`` in
@@ -166,7 +167,7 @@
 about that some on the next page.
 
 A protocol like HTTP uses a socket for only one transfer. The client sends a
-request, the reads a reply.  That's it. The socket is discarded. This means that
+request, then reads a reply.  That's it. The socket is discarded. This means that
 a client can detect the end of the reply by receiving 0 bytes.
 
 But if you plan to reuse your socket for further transfers, you need to realize
@@ -353,9 +354,9 @@
 thing to do - give it a nice long timeout (say a minute) unless you have good
 reason to do otherwise.
 
-In return, you will get three lists. They have the sockets that are actually
+In return, you will get three lists. They're the sockets that are actually
 readable, writable and in error. Each of these lists is a subset (possibly
-empty) of the corresponding list you passed in. And if you put a socket in more
+empty) of the corresponding argument list. And if you put a socket in more
 than one input list, it will only be (at most) in one output list.
 
 If a socket is in the output readable list, you can be