Minor typo/grammar/wording/markup fixes (#991)

pep-0589.rst

@@ -15,7 +15,7 @@ Abstract
 ========
 
 PEP 484 [#PEP-484]_ defines the type ``Dict[K, V]`` for uniform
-dictionaries, where each value has the same type and arbitrary key
+dictionaries, where each value has the same type, and arbitrary key
 values are supported.  It doesn't properly support the common pattern
 where the type of a dictionary value depends on the string value of
 the key.  This PEP proposes a type constructor ``typing.TypedDict`` to
@@ -68,7 +68,7 @@ consider a dictionary object that has exactly two valid string keys,
 it is too lenient, as arbitrary string keys can be used, and arbitrary
 values are valid.  Similarly, ``Dict[str, Union[str, int]]`` is too
 general, as the value for key ``'name'`` could be an ``int``, and
-arbirary string keys are allowed.  Also, the type of a subscription
+arbitrary string keys are allowed.  Also, the type of a subscription
 expression such as ``d['name']`` (assuming ``d`` to be a dictionary of
 this type) would be ``Union[str, int]``, which is too wide.
 
@@ -86,10 +86,10 @@ Specification
 
 A TypedDict type represents dictionary objects with a specific set of
 string keys, and with specific value types for each valid key.  Each
-string key can be either required (it can't be omitted) or
+string key can be either required (it must be present) or
 non-required (it doesn't need to exist).
 
-The PEP proposes two ways of defining TypedDict types.  The first uses
+This PEP proposes two ways of defining TypedDict types.  The first uses
 a class-based syntax.  The second is an alternative
 assignment-based syntax that is provided for backwards compatibility,
 to allow the feature to be backported to older Python versions.  The
@@ -126,10 +126,10 @@ A TypedDict type can be defined using the class definition syntax with
 ``str``) and ``'year'`` (with type ``int``).
 
 A type checker should validate that the body of a class-based
-TypedDict definition conforms to these rules:
+TypedDict definition conforms to the following rules:
 
-* The class body should only contain an optional docstring, followed
-  by lines with item definitions of the form ``key: value_type``.  The
+* The class body should only contain lines with item definitions of the
+  form ``key: value_type``, optionally preceded by a docstring.  The
   syntax for item definitions is identical to attribute annotations,
   but there must be no initializer, and the key name actually refers
   to the string value of the key instead of an attribute name.
@@ -198,7 +198,7 @@ key, and the ``'name'`` key is missing::
     movie2: Movie = {'title': 'Blade Runner',
                      'year': 1982}
 
-The created TypedDict type object is not a real class object.  These
+The created TypedDict type object is not a real class object.  Here
 are the only uses of the type a type checker is expected to allow:
 
 * It can be used in type annotations and in any context where an
@@ -292,7 +292,7 @@ these are valid::
 
 A type checker is only expected to support a literal ``False`` or
 ``True`` as the value of the ``total`` argument.  ``True`` is the
-default, and makes all items defined the class body be required.
+default, and makes all items defined in the class body be required.
 
 The totality flag only applies to items defined in the body of the
 TypedDict definition.  Inherited items won't be affected, and instead
@@ -313,8 +313,9 @@ resembles the traditional syntax for defining named tuples::
 
 It is also possible to specify totality using the alternative syntax::
 
-    Movie = TypedDict('Movie', {'name': str,
-                                'year': int}, total=False)
+    Movie = TypedDict('Movie',
+                      {'name': str, 'year': int},
+                      total=False)
 
 The semantics are equivalent to the class-based syntax.  This syntax
 doesn't support inheritance, however, and there is no way to