iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 586: Small wording changes from review (#993)

This commit is contained in:
Guido van Rossum 2019-04-15 19:03:35 -07:00 committed by GitHub
parent c4c4bd7b9c
commit 7a0b6e7ef0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 10 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
pep-0586.rst
View File

@ -22,7 +22,7 @@ only expressions that have literally the value "4"::
def accepts_only_four(x: Literal[4]) -> None: def accepts_only_four(x: Literal[4]) -> None:
pass pass
accepts_only_four(4) # Ok accepts_only_four(4) # OK
accepts_only_four(19) # Rejected accepts_only_four(19) # Rejected
Motivation and Rationale Motivation and Rationale
@ -76,7 +76,7 @@ This section outlines the baseline behavior of literal types.
Core behavior 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 concrete value. For example, if we define some variable ``foo`` to have
type ``Literal[3]``, we are declaring that ``foo`` must be exactly equal type ``Literal[3]``, we are declaring that ``foo`` must be exactly equal
to ``3`` and no other value. 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, If type checkers choose to use more sophisticated inference strategies,
they should avoid being too over-zealous while doing so. they should avoid being too over-zealous while doing so.
For example, one strategy that does *not* work is always assuming expressions For example, one strategy that does *not* work is always assuming
are Literal types. This naive strategy would cause programs like the 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:: following to start failing when they previously did not::
# If a type checker infers 'var' has type Literal[3] # If a type checker infers 'var' has type Literal[3]
@ -454,7 +455,7 @@ types. For example, consider ``open``::
@overload @overload
def open(path: _PathType, mode: str) -> IO[Any]: ... 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. we would break any code that does not pass in a literal string expression.
For example, code like this would be broken:: 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. by using ``S = Literal["foo"]`` instead.
**Note:** Literal types and generics deliberately interact in only very **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 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 almost certainly likely find Literal types as proposed in this PEP to be
insufficient for their needs. insufficient for their needs.
@ -600,8 +601,8 @@ True dependent types/integer generics
This proposal is essentially describing adding a very simplified This proposal is essentially describing adding a very simplified
dependent type system to the PEP 484 ecosystem. One obvious extension dependent type system to the PEP 484 ecosystem. One obvious extension
is to implement a full-fledged dependent type system that let users would be to implement a full-fledged dependent type system that lets users
predicate types based on their values in arbitrary ways. This would predicate types based on their values in arbitrary ways. That would
let us write signatures like the below:: let us write signatures like the below::
# A vector has length 'n', containing elements of type 'T' # 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. 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 for this PEP: it would require a far more substantial amount of implementation
work, discussion, and research to complete compared to the current proposal. work, discussion, and research to complete compared to the current proposal.