From 7a0b6e7ef055bae4d9f07a5f0947db82d650d75f Mon Sep 17 00:00:00 2001 From: Guido van Rossum Date: Mon, 15 Apr 2019 19:03:35 -0700 Subject: [PATCH] PEP 586: Small wording changes from review (#993) --- pep-0586.rst | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/pep-0586.rst b/pep-0586.rst index 98ef10157..eb0ce2739 100644 --- a/pep-0586.rst +++ b/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.