Merge pull request #1109 from tonkoandrew/master

Aspell check fixes

docs/examples/comparing_publishing_sync_async.rst

@@ -1,7 +1,7 @@
 Comparing Message Publishing with BlockingConnection and SelectConnection
 =========================================================================
 
-For those doing simple, non-asynchronous programing, :py:meth:`pika.adapters.blocking_connection.BlockingConnection` proves to be the easiest way to get up and running with Pika to publish messages.
+For those doing simple, non-asynchronous programming, :py:meth:`pika.adapters.blocking_connection.BlockingConnection` proves to be the easiest way to get up and running with Pika to publish messages.
 
 In the following example, a connection is made to RabbitMQ listening to port *5672* on *localhost* using the username *guest* and password *guest* and virtual host */*. Once connected, a channel is opened and a message is published to the *test_exchange* exchange using the *test_routing_key* routing key. The BasicProperties value passed in sets the message to delivery mode *1* (non-persisted) with a content-type of *text/plain*. Once the message is published, the connection is closed::
 

docs/examples/heartbeat_and_blocked_timeouts.rst

@@ -4,9 +4,9 @@ Ensuring well-behaved connection with heartbeat and blocked-connection timeouts
 
 This example demonstrates explicit setting of heartbeat and blocked connection timeouts.
 
-Starting with RabbitMQ 3.5.5, the broker's default hearbeat timeout decreased from 580 seconds to 60 seconds. As a result, applications that perform lengthy processing in the same thread that also runs their Pika connection may experience unexpected dropped connections due to heartbeat timeout. Here, we specify an explicit lower bound for heartbeat timeout.
+Starting with RabbitMQ 3.5.5, the broker's default heartbeat timeout decreased from 580 seconds to 60 seconds. As a result, applications that perform lengthy processing in the same thread that also runs their Pika connection may experience unexpected dropped connections due to heartbeat timeout. Here, we specify an explicit lower bound for heartbeat timeout.
 
-When RabbitMQ broker is running out of certain resources, such as memory and disk space, it may block connections that are performing resource-consuming operations, such as publishing messages. Once a connection is blocked, RabbiMQ stops reading from that connection's socket, so no commands from the client will get through to the broker on that connection until the broker unblocks it. A blocked connection may last for an indefinite period of time, stalling the connection and possibly resulting in a hang (e.g., in BlockingConnection) until the connection is unblocked. Blocked Connectin Timeout is intended to interrupt (i.e., drop) a connection that has been blocked longer than the given timeout value.
+When RabbitMQ broker is running out of certain resources, such as memory and disk space, it may block connections that are performing resource-consuming operations, such as publishing messages. Once a connection is blocked, RabbitMQ stops reading from that connection's socket, so no commands from the client will get through to the broker on that connection until the broker unblocks it. A blocked connection may last for an indefinite period of time, stalling the connection and possibly resulting in a hang (e.g., in BlockingConnection) until the connection is unblocked. Blocked Connection Timeout is intended to interrupt (i.e., drop) a connection that has been blocked longer than the given timeout value.
 
 Example of configuring heartbeat and blocked-connection timeouts::
 
@@ -15,7 +15,7 @@ Example of configuring heartbeat and blocked-connection timeouts::
 
     def main():
 
-        # NOTE: These paramerers work with all Pika connection types
+        # NOTE: These parameters work with all Pika connection types
         params = pika.ConnectionParameters(heartbeat_interval=600,
                                            blocked_connection_timeout=300)
 

docs/examples/tls_server_authentication.rst

@@ -4,7 +4,7 @@ This examples demonstrates a TLS session with RabbitMQ using server authenticati
 
 It was tested against RabbitMQ 3.6.10, using Python 3.6.1 and pre-release Pika `0.11.0`
 
-Note the use of `ssl_version=ssl.PROTOCOL_TLSv1`. The recent verions of RabbitMQ disable older versions of
+Note the use of `ssl_version=ssl.PROTOCOL_TLSv1`. The recent versions of RabbitMQ disable older versions of
 SSL due to security vulnerabilities.
 
 See https://www.rabbitmq.com/ssl.html for certificate creation and rabbitmq SSL configuration instructions.

docs/intro.rst

@@ -122,4 +122,4 @@ Example::
 
 .. rubric:: Footnotes
 
-.. [#f1] "more effective flow control mechanism that does not require cooperation from clients and reacts quickly to prevent the broker from exhausing memory - see http://www.rabbitmq.com/extensions.html#memsup" from http://lists.rabbitmq.com/pipermail/rabbitmq-announce/attachments/20100825/2c672695/attachment.txt
+.. [#f1] "more effective flow control mechanism that does not require cooperation from clients and reacts quickly to prevent the broker from exhausting memory - see http://www.rabbitmq.com/extensions.html#memsup" from http://lists.rabbitmq.com/pipermail/rabbitmq-announce/attachments/20100825/2c672695/attachment.txt

docs/modules/adapters/index.rst

@@ -1,7 +1,7 @@
 Connection Adapters
 ===================
 Pika uses connection adapters to provide a flexible method for adapting pika's
-core communication to different IOLoop implementations. In addition to asynchronous adapters, there is the :class:`BlockingConnection <pika.adapters.blocking_connection.BlockingConnection>` adapter that provides a more idomatic procedural approach to using Pika.
+core communication to different IOLoop implementations. In addition to asynchronous adapters, there is the :class:`BlockingConnection <pika.adapters.blocking_connection.BlockingConnection>` adapter that provides a more idiomatic procedural approach to using Pika.
 
 Adapters
 --------

docs/version_history.rst

@@ -163,14 +163,14 @@ High-level summary of notable changes:
   adapter.
 - Non-backward-compatible changes in `Channel.add_on_return_callback` callback's
   signature.
-- The `AsynchoreConnection` adapter was retired
+- The `AsyncoreConnection` adapter was retired
 
 **Details**
 
 Python 3.x: this release introduces python 3.x support. Tested on Python 3.3
 and 3.4.
 
-`AsynchoreConnection`: Retired this legacy adapter to reduce maintenance burden;
+`AsyncoreConnection`: Retired this legacy adapter to reduce maintenance burden;
 the recommended replacement is the `SelectConnection` adapter.
 
 `SelectConnection`: ioloop was refactored for compatibility with other ioloops.
@@ -194,7 +194,7 @@ changes:
     to process pending I/O, additional callbacks will be suppressed whenever
     `BlockingConnection.process_data_events` and `BlockingConnection.sleep` are
     nested in any combination; in that case, the callback information will be
-    bufferred and dispatched once nesting unwinds and control returns to the
+    buffered and dispatched once nesting unwinds and control returns to the
     level-zero dispatcher.
   - `BlockingConnection.connect`: this method was removed in favor of the
     constructor as the only way to establish connections; this reduces