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

pep-0586.rst

@@ -22,9 +22,15 @@ 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
 
+    four = 4
+    accepts_only_four(four)  # Rejected (not a literal)
+
+    four: Final = 4          # See PEP 591
+    accepts_only_four(four)  # OK if PEP 591 is accepted
+
 Motivation and Rationale
 ========================
 
@@ -76,7 +82,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 +347,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 +461,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 +511,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 +607,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 +622,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.