More typos found by Tim Tvrtković.

pep-3156.txt

@@ -603,14 +603,14 @@ use a different transport and protocol interface.
     a default context is created it is up to the implementation to
     configure reasonable defaults.  The reference implementation
     currently uses ``PROTOCOL_SSLv23`` and sets the ``OP_NO_SSLv2``
-    option, calls ``set_default_verify_paths()`` and sets verify_mode
+    option, calls ``set_default_verify_paths()`` and sets ``verify_mode``
     to ``CERT_REQUIRED``.  In addition, whenever the context (default
-    or otherwise) specifies a verify_mode of ``CERT_REQUIRED`` or
+    or otherwise) specifies a ``verify_mode`` of ``CERT_REQUIRED`` or
     ``CERT_OPTIONAL``, if a hostname is given, immediately after a
     successful handshake ``ssl.match_hostname(peercert, hostname)`` is
     called, and if this raises an exception the conection is closed.
-    (To avoid this behavior, pass in an SSL context that ha
-    verify_mode set to ``CERT_NONE``.  But this means you are not
+    (To avoid this behavior, pass in an SSL context that has
+    ``verify_mode`` set to ``CERT_NONE``.  But this means you are not
     secure, and vulnerable to for example man-in-the-middle attacks.)
 
   - ``family``, ``proto``, ``flags``: Address family, protocol and
@@ -899,7 +899,7 @@ These methods are only supported on UNIX.
   ``sig`` is received, arrange for ``callback(*args)`` to be called.
   Specifying another callback for the same signal replaces the
   previous handler (only one handler can be active per signal).  The
-  ``sig`` must be a valid sigal number defined in the ``signal``
+  ``sig`` must be a valid signal number defined in the ``signal``
   module.  If the signal cannot be handled this raises an exception:
   ``ValueError`` if it is not a valid signal or if it is an
   uncatchable signal (e.g. ``SIGKILL``), ``RuntimeError`` if this
@@ -1372,7 +1372,10 @@ context.  (See the "Context" section way above.)
   the transport's ``set_write_buffer_limits()`` method.
 
 - ``resume_writing()``.  Tells the protocol that it is safe to start
-  writing data to the transport again.  Note that this may be cal
+  writing data to the transport again.  Note that this may be called
+  directly by the transport's ``write()`` method (as opposed to being
+  called indirectly using ``call_soon()``), so that the protocol may
+  be aware of its paused state immediately after ``write()`` returns.
 
 - ``connection_lost(exc)``.  The transport has been closed or aborted,
   has detected that the other end has closed the connection cleanly,
@@ -1423,7 +1426,7 @@ Here is a chart indicating the order and multiplicity of calls:
 Subprocess Protocol
 '''''''''''''''''''
 
-Subprocess protocols have ``connection_made()``, ``connection_lost()``
+Subprocess protocols have ``connection_made()``, ``connection_lost()``,
 ``pause_writing()`` and ``resume_writing()`` methods with the same
 signatures as stream protocols.  In addition, they have the following
 methods:
@@ -1635,9 +1638,9 @@ task's exception.
 Cancelling a task that's not done yet throws an
 ``asyncio.CancelledError`` exception into the coroutine.  If the
 coroutine doesn't catch this (or if it re-raises it) the task will be
-marked as cancelled (i.e., ``cancelled()`` will return ``True``; but
+marked as cancelled (i.e., ``cancelled()`` will return ``True``); but
 if the coroutine somehow catches and ignores the exception it may
-continue to execute (and ``cancelled()`` will return ``False``.
+continue to execute (and ``cancelled()`` will return ``False``).
 
 Tasks are also useful for interoperating between coroutines and
 callback-based frameworks like Twisted.  After converting a coroutine
@@ -1713,7 +1716,7 @@ are:
     internal buffer.  This unblocks a blocked reading coroutine if it
     provides sufficient data to fulfill the reader's contract.
 
-  - ``feed_eof()``: Signal the end of the buffer.  This unclocks a
+  - ``feed_eof()``: Signal the end of the buffer.  This unblocks a
     blocked reading coroutine.  No more data should be fed to the
     reader after this call.
 
@@ -1766,7 +1769,7 @@ the ``asyncio.locks`` submodule.  Queus modeled after those in the
 ``asyncio.queues`` submodule.
 
 In general these have a close correspondence to their threaded
-counterparts, however, blocking methods (e.g. ``aqcuire()`` on locks,
+counterparts, however, blocking methods (e.g. ``acquire()`` on locks,
 ``put()`` and ``get()`` on queues) are coroutines, and timeout
 parameters are not provided (you can use ``asyncio.wait_for()`` to add
 a timeout to a blocking call, however).
@@ -1809,13 +1812,13 @@ Queues
 The following classes and exceptions are provided by ``asyncio.queues``.
 
 - ``Queue``: a standard queue, with methods ``get()``, ``put()`` (both
-  coroutines), ``get_nowait()``, ''put_nowait()'', ``empty()``,
+  coroutines), ``get_nowait()``, ``put_nowait()``, ``empty()``,
   ``full()``, ``qsize()``, and ``maxsize()``.
 
 - ``PriorityQueue``: a subclass of ``Queue`` that retrieves entries
   in priority order (lowest first).
 
-- ``LifoQueue``: a aubclass of ``Queue`` that retrieves the most
+- ``LifoQueue``: a subclass of ``Queue`` that retrieves the most
   recently added entries first.
 
 - ``JoinableQueue``: a subclass of ``Queue`` with ``task_done()`` and
@@ -1897,7 +1900,7 @@ status allows revising these decisions for Python 3.5.)
   zero and sometimes named constants (whose value is also zero)?
 
 - Do we need another inquiry method to tell whether the loop is in the
-  process of stopping?)
+  process of stopping?
 
 - A fuller public API for Handle?  What's the use case?