One space after period for proportional fonts

6 files changed, 22 insertions, 22 deletions

diff --git a/docs/includes/introduction.txt b/docs/includes/introduction.txt
index 813ba219..71b66eeb 100644
--- a/docs/includes/introduction.txt
+++ b/docs/includes/introduction.txt
@@ -34,7 +34,7 @@ Features
         $ pip install librabbitmq
 
     * Virtual transports makes it really easy to add support for non-AMQP
-      transports.  There is already built-in support for `Redis`_,
+      transports. There is already built-in support for `Redis`_,
       `Amazon SQS`_, `ZooKeeper`_, `SoftLayer MQ`_ and `Pyro`_.
 
     * In-memory transport for unit testing.
@@ -141,7 +141,7 @@ Quick overview
         # the declare above, makes sure the video queue is declared
         # so that the messages can be delivered.
         # It's a best practice in Kombu to have both publishers and
-        # consumers declare the queue.  You can also declare the
+        # consumers declare the queue. You can also declare the
         # queue manually using:
         #     video_queue(conn).declare()
 
@@ -239,7 +239,7 @@ There are some concepts you should be familiar with before starting:
 
     * Routing keys
 
-        Every message has a routing key.  The interpretation of the routing
+        Every message has a routing key. The interpretation of the routing
         key depends on the exchange type. There are four default exchange
         types defined by the AMQP standard, and vendors can define custom
         types (so see your vendors manual for details).
diff --git a/docs/userguide/connections.rst b/docs/userguide/connections.rst
index ab63a3bf..e3ceaa07 100644
--- a/docs/userguide/connections.rst
+++ b/docs/userguide/connections.rst
@@ -146,7 +146,7 @@ keyword arguments, these are:
 :connect_timeout: Timeout in seconds for connecting to the
   server. May not be supported by the specified transport.
 :transport_options: A dict of additional connection arguments to
-  pass to alternate kombu channel implementations.  Consult the transport
+  pass to alternate kombu channel implementations. Consult the transport
   documentation for available options.
 
 AMQP Transports
@@ -161,7 +161,7 @@ There are 4 transports available for AMQP use.
    automatically compiles the C library.
 3. ``amqp`` tries to use ``librabbitmq`` but falls back to ``pyamqp``.
 4. ``qpid`` uses the pure Python library ``qpid.messaging``, automatically
-   installed with Kombu.  The Qpid library uses AMQP, but uses custom
+   installed with Kombu. The Qpid library uses AMQP, but uses custom
    extensions specifically supported by the Apache Qpid Broker.
 
 For the highest performance, you should install the ``librabbitmq`` package.
diff --git a/docs/userguide/consumers.rst b/docs/userguide/consumers.rst
index 02ed2cf0..3a150e5a 100644
--- a/docs/userguide/consumers.rst
+++ b/docs/userguide/consumers.rst
@@ -10,7 +10,7 @@ Basics
 ======
 
 The :class:`Consumer` takes a connection (or channel) and a list of queues to
-consume from.  Several consumers can be mixed to consume from different
+consume from. Several consumers can be mixed to consume from different
 channels, as they all bind to the same connection, and ``drain_events`` will
 drain events from all channels on that connection.
 
diff --git a/docs/userguide/introduction.rst b/docs/userguide/introduction.rst
index b540e1e3..0023c6d0 100644
--- a/docs/userguide/introduction.rst
+++ b/docs/userguide/introduction.rst
@@ -11,7 +11,7 @@ What is messaging?
 
 In times long ago people didn't have email.
 They had the postal service, which with great courage would deliver mail
-from hand to hand all over the globe.  Soldiers deployed at wars far away could only
+from hand to hand all over the globe. Soldiers deployed at wars far away could only
 communicate with their families through the postal service, and
 posting a letter would mean that the recipient wouldn't actually
 receive the letter until weeks or months, sometimes years later.
@@ -24,8 +24,8 @@ be news to anyone, but why would applications?
 
 One example is banks.
 When you transfer money from one bank to another, your bank sends
-a message to a central clearinghouse.  The clearinghouse
-then records and coordinates the transaction.  Banks
+a message to a central clearinghouse. The clearinghouse
+then records and coordinates the transaction. Banks
 need to send and receive millions and millions of
 messages every day, and losing a single message would mean either losing
 your money (bad) or the banks money (very bad)
@@ -34,7 +34,7 @@ Another example is the stock exchanges, which also have a need
 for very high message throughputs and have strict reliability
 requirements.
 
-Email is a great way for people to communicate.  It is much faster
+Email is a great way for people to communicate. It is much faster
 than using the postal service, but still using email as a means for
 programs to communicate would be like the soldier above, waiting
 for signs of life from his girlfriend back home.
@@ -48,7 +48,7 @@ Messaging Scenarios
 
   The request/reply pattern works like the postal service example.
   A message is addressed to a single recipient, with a return address
-  printed on the back.  The recipient may or may not reply to the
+  printed on the back. The recipient may or may not reply to the
   message by sending it back to the original sender.
 
   Request-Reply is achieved using *direct* exchanges.
@@ -67,7 +67,7 @@ Messaging Scenarios
   interested in.
 
   If no consumers subscribe to the topic, then the message
-  will not be delivered to anyone.  If several consumers
+  will not be delivered to anyone. If several consumers
   subscribe to the topic, then the message will be delivered
   to all of them.
 
@@ -78,8 +78,8 @@ Messaging Scenarios
 Reliability
 ===========
 
-For some applications reliability is very important.  Losing a message is
-a critical situation that must never happen.  For other applications
+For some applications reliability is very important. Losing a message is
+a critical situation that must never happen. For other applications
 losing a message is fine, it can maybe recover in other ways,
 or the message is resent anyway as periodic updates.
 
@@ -92,7 +92,7 @@ AMQP defines two built-in delivery modes:
 * transient
 
     Messages may or may not be written to disk, as the broker sees fit
-    to optimize memory contents.  The messages will not survive a broker
+    to optimize memory contents. The messages won't survive a broker
     restart.
 
 Transient messaging is by far the fastest way to send and receive messages,
diff --git a/docs/userguide/pools.rst b/docs/userguide/pools.rst
index 3c4b9d81..e30bd6a9 100644
--- a/docs/userguide/pools.rst
+++ b/docs/userguide/pools.rst
@@ -26,7 +26,7 @@ The connection pool group
 
 The connection pools are available as :attr:`kombu.pools.connections`.
 This is a pool group, which means you give it a connection instance,
-and you get a pool instance back.  We have one pool per connection
+and you get a pool instance back. We have one pool per connection
 instance to support multiple connections in the same app.
 All connection instances with the same connection parameters will
 get the same pool:
@@ -58,7 +58,7 @@ Let's acquire and release a connection:
     The ``block=True`` here means that the acquire call will block
     until a connection is available in the pool.
     Note that this will block forever in case there is a deadlock
-    in your code where a connection is not released.  There
+    in your code where a connection is not released. There
     is a ``timeout`` argument you can use to safeguard against this
     (see :meth:`kombu.connection.Resource.acquire`).
 
@@ -66,7 +66,7 @@ Let's acquire and release a connection:
     left in the pool an :class:`kombu.exceptions.ConnectionLimitExceeded`
     exception will be raised.
 
-That's about it.  If you need to connect to multiple brokers
+That's about it. If you need to connect to multiple brokers
 at once you can do that too:
 
 .. code-block:: python
@@ -137,7 +137,7 @@ Resetting all pools
 -------------------
 
 You can close all active connections and reset all pool groups by
-using the :func:`kombu.pools.reset` function.  Note that this
+using the :func:`kombu.pools.reset` function. Note that this
 will not respect anything currently using these connections,
 so will just drag the connections away from under their feet:
 you should be very careful before you use this.
diff --git a/docs/userguide/serialization.rst b/docs/userguide/serialization.rst
index 799c565c..e63b743a 100644
--- a/docs/userguide/serialization.rst
+++ b/docs/userguide/serialization.rst
@@ -39,7 +39,7 @@ Each option has its advantages and disadvantages.
 
     The primary disadvantage to `JSON` is that it limits you to
     the following data types: strings, Unicode, floats, boolean,
-    dictionaries, and lists.  Decimals and dates are notably missing.
+    dictionaries, and lists. Decimals and dates are notably missing.
 
     Also, binary data will be transferred using Base64 encoding, which
     will cause the transferred data to be around 34% larger than an
@@ -85,7 +85,7 @@ Each option has its advantages and disadvantages.
 To instruct `Kombu` to use an alternate serialization method,
 use one of the following options.
 
-    1.  Set the serialization option on a per-producer basis:
+    1. Set the serialization option on a per-producer basis:
 
         .. code-block:: pycon
 
@@ -93,7 +93,7 @@ use one of the following options.
             ...                     exchange=exchange,
             ...                     serializer='yaml')
 
-    2.  Set the serialization option per message:
+    2. Set the serialization option per message:
 
         .. code-block:: pycon