From 0c62cdc3aef56e540da4767fdaf37ed7f1098698 Mon Sep 17 00:00:00 2001 From: Guido van Rossum Date: Mon, 15 Apr 2019 15:27:42 -0700 Subject: [PATCH 1/2] Small wording changes found during review; and expanded example in Abstract The additions to the Abstract example may be controversial, I'm happy to change these -- or anything else -- if you're uncomfortable with my suggestions. --- pep-0586.rst | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/pep-0586.rst b/pep-0586.rst index 98ef1015795..b8fb86ae705 100644 --- a/pep-0586.rst +++ b/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. From 7b381663d06d93866c18e9bcf1598a45642b7359 Mon Sep 17 00:00:00 2001 From: Guido van Rossum Date: Mon, 15 Apr 2019 18:59:40 -0700 Subject: [PATCH 2/2] Delete the new examples I added --- pep-0586.rst | 6 ------ 1 file changed, 6 deletions(-) diff --git a/pep-0586.rst b/pep-0586.rst index b8fb86ae705..eb0ce27394f 100644 --- a/pep-0586.rst +++ b/pep-0586.rst @@ -25,12 +25,6 @@ only expressions that have literally the value "4":: 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 ========================