pep-0492: Fix terminology around coroutine object

pep-0492.txt

@@ -112,7 +112,7 @@ Key properties of *coroutines*:
   ``CO_GENERATOR`` flags set.
 
 * Regular generators, when called, return a *generator object*;
-  similarly, coroutines return a *coroutine object*.
+  similarly, coroutines return a *coroutine* object.
 
 * ``StopIteration`` exceptions are not propagated out of coroutines,
   and are replaced with a ``RuntimeError``.  For regular generators
@@ -132,7 +132,7 @@ allows interoperability between existing *generator-based coroutines*
 in asyncio and *native coroutines* introduced by this PEP.
 
 The function applies ``CO_COROUTINE`` flag to generator-function's code
-object, making it return a *coroutine object*.
+object, making it return a *coroutine* object.
 
 The function can be used as a decorator, since it modifies generator-
 functions in-place and returns them.
@@ -160,10 +160,11 @@ It uses the ``yield from`` implementation with an extra step of
 validating its argument.  ``await`` only accepts an *awaitable*, which
 can be one of:
 
-* A *native coroutine object* returned from a *native coroutine*.
+* A *native coroutine* object returned from a *native coroutine
+  function*.
 
-* A *generator-based coroutine object* returned from a generator
-  decorated with ``types.coroutine()``.
+* A *generator-based coroutine* object returned from a *generator
+  function* decorated with ``types.coroutine()``.
 
 * An object with an ``__await__`` method returning an iterator.
 
@@ -590,15 +591,15 @@ remains unchanged.**
 Great effort has been made to make sure that coroutines and
 generators are treated as distinct concepts:
 
-1. *Native coroutine objects* do not implement ``__iter__`` and
+1. *Native coroutine* objects do not implement ``__iter__`` and
    ``__next__`` methods.  Therefore, they cannot be iterated over or
    passed to ``iter()``, ``list()``, ``tuple()`` and other built-ins.
    They also cannot be used in a ``for..in`` loop.
 
    An attempt to use ``__iter__`` or ``__next__`` on a *native
-   coroutine object* will result in a ``TypeError``.
+   coroutine* object will result in a ``TypeError``.
 
-2. *Plain generators* cannot ``yield from`` *native coroutine objects*:
+2. *Plain generators* cannot ``yield from`` *native coroutines*:
    doing so will result in a ``TypeError``.
 
 3. *generator-based coroutines* (for asyncio code must be decorated
@@ -606,7 +607,7 @@ generators are treated as distinct concepts:
    objects*.
 
 4. ``inspect.isgenerator()`` and ``inspect.isgeneratorfunction()``
-   return ``False`` for *native coroutine objects* and *native
+   return ``False`` for *native coroutine* objects and *native
    coroutine functions*.
 
 
@@ -614,13 +615,13 @@ Coroutine object methods
 ''''''''''''''''''''''''
 
 Coroutines are based on generators internally, thus they share the
-implementation.  Similarly to generator objects, coroutine objects have
+implementation.  Similarly to generator objects, *coroutines* have
 ``throw()``, ``send()`` and ``close()`` methods.  ``StopIteration`` and
-``GeneratorExit`` play the same role for coroutine objects (although
+``GeneratorExit`` play the same role for coroutines (although
 PEP 479 is enabled by default for coroutines).  See PEP 342, PEP 380,
 and Python Documentation [11]_ for details.
 
-``throw()``, ``send()`` methods for coroutine objects are used to push
+``throw()``, ``send()`` methods for *coroutines* are used to push
 values and raise errors into *Future-like* objects.
 
 
@@ -668,7 +669,7 @@ New Standard Library Functions
   details.
 
 * ``inspect.iscoroutine(obj)`` returns ``True`` if ``obj`` is a
-  *coroutine object*.
+  *coroutine* object.
 
 * ``inspect.iscoroutinefunction(obj)`` returns ``True`` if ``obj`` is a
   *coroutine function*.
@@ -677,8 +678,8 @@ New Standard Library Functions
   in ``await`` expression.  See `Await Expression`_ for details.
 
 * ``sys.set_coroutine_wrapper(wrapper)`` allows to intercept creation
-  of *coroutine objects*.  ``wrapper`` must be a callable that accepts
-  one argument: a *coroutine object* or ``None``.  ``None`` resets the
+  of *coroutine* objects.  ``wrapper`` must be a callable that accepts
+  one argument: a *coroutine* object or ``None``.  ``None`` resets the
   wrapper.  If called twice, the new wrapper replaces the previous one.
   The function is thread-specific.  See `Debugging Features`_ for more
   details.
@@ -691,28 +692,28 @@ New Standard Library Functions
 Glossary
 ========
 
-:Native coroutine:
+:Native coroutine function:
     A coroutine function is declared with ``async def``. It uses
     ``await`` and ``return value``; see `New Coroutine Declaration
     Syntax`_ for details.
 
-:Native coroutine object:
+:Native coroutine:
     Returned from a native coroutine function. See `Await Expression`_
     for details.
 
-:Generator-based coroutine:
+:Generator-based coroutine function:
     Coroutines based on generator syntax.  Most common example are
     functions decorated with ``@asyncio.coroutine``.
 
-:Generator-based coroutine object:
+:Generator-based coroutine:
     Returned from a generator-based coroutine function.
 
 :Coroutine:
     Either *native coroutine* or *generator-based coroutine*.
 
 :Coroutine object:
-    Either *native coroutine object* or *generator-based coroutine
-    object*.
+    Either *native coroutine* object or *generator-based coroutine*
+    object.
 
 :Future-like object:
     An object with an ``__await__`` method, or a C object with
@@ -723,7 +724,7 @@ Glossary
     Expression`_ for details.
 
 :Awaitable:
-    A *Future-like* object or a *coroutine object*.  See `Await
+    A *Future-like* object or a *coroutine* object.  See `Await
     Expression`_ for details.
 
 :Asynchronous context manager: