PEP 586: Small wording changes from review; expanded example in Abstract

pep-0586.rst

@@ -22,7 +22,7 @@ only expressions that have literally the value "4"::
     def accepts_only_four(x: Literal[4]) -> None:
         pass
 
-    accepts_only_four(4)   # Ok
+    accepts_only_four(4)   # OK
     accepts_only_four(19)  # Rejected
 
 Motivation and Rationale
@@ -76,7 +76,7 @@ This section outlines the baseline behavior of literal types.
 Core behavior
 -------------
 
-Literal types indicate a variable has a specific and
+Literal types indicate that a variable has a specific and
 concrete value. For example, if we define some variable ``foo`` to have
 type ``Literal[3]``, we are declaring that ``foo`` must be exactly equal
 to ``3`` and no other value.
@@ -341,8 +341,9 @@ always infer that ``x`` is of type ``str`` in the above example.
 If type checkers choose to use more sophisticated inference strategies,
 they should avoid being too over-zealous while doing so.
 
-For example, one strategy that does *not* work is always assuming expressions
-are Literal types. This naive strategy would cause programs like the
+For example, one strategy that does *not* work is always assuming
+literal values occurring in expressions have the corresponding Literal
+type.  This naive strategy would cause programs like the
 following to start failing when they previously did not::
 
     # If a type checker infers 'var' has type Literal[3]
@@ -454,7 +455,7 @@ types. For example, consider ``open``::
    @overload
    def open(path: _PathType, mode: str) -> IO[Any]: ...
 
-If we change the signature of ``open`` to use just the first two overloads,
+If we were to change the signature of ``open`` to use just the first two overloads,
 we would break any code that does not pass in a literal string expression.
 For example, code like this would be broken::
 
@@ -504,7 +505,7 @@ the above example is essentially pointless: we can get equivalent behavior
 by using ``S = Literal["foo"]`` instead.
 
 **Note:** Literal types and generics deliberately interact in only very
-basic and limited ways. In particular, libraries that want to typecheck
+basic and limited ways. In particular, libraries that want to type check
 code containing an heavy amount of numeric or numpy-style manipulation will
 almost certainly likely find Literal types as proposed in this PEP to be
 insufficient for their needs.
@@ -600,8 +601,8 @@ True dependent types/integer generics
 
 This proposal is essentially describing adding a very simplified
 dependent type system to the PEP 484 ecosystem. One obvious extension
-is to implement a full-fledged dependent type system that let users
-predicate types based on their values in arbitrary ways. This would
+would be to implement a full-fledged dependent type system that lets users
+predicate types based on their values in arbitrary ways. That would
 let us write signatures like the below::
 
    # A vector has length 'n', containing elements of type 'T'
@@ -615,7 +616,7 @@ let us write signatures like the below::
 
 At the very least, it would be useful to add some form of integer generics.
 
-Although such a type system would certainly be useful, it’s out-of-scope
+Although such a type system would certainly be useful, it’s out of scope
 for this PEP: it would require a far more substantial amount of implementation
 work, discussion, and research to complete compared to the current proposal.