[Python-checkins] peps: ASCIIfy PEP 483
chris.angelico
python-checkins at python.org
Fri Jan 9 19:29:54 CET 2015
https://hg.python.org/peps/rev/003429214c06
changeset: 5664:003429214c06
user: Chris Angelico <rosuav at gmail.com>
date: Sat Jan 10 05:28:21 2015 +1100
summary:
ASCIIfy PEP 483
files:
pep-0483.txt | 56 ++++++++++++++++++++--------------------
1 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/pep-0483.txt b/pep-0483.txt
--- a/pep-0483.txt
+++ b/pep-0483.txt
@@ -40,8 +40,8 @@
We define a new relationship, is-consistent-with, which is similar to
is-subclass-of, except it is not transitive when the new type **Any** is
involved. (Neither relationship is symmetric.) Assigning x to y is OK if
-the type of x is consistent with the type of y. (Compare this to “... if
-the type of x is a subclass of the type of y,” which states one of the
+the type of x is consistent with the type of y. (Compare this to "... if
+the type of x is a subclass of the type of y," which states one of the
fundamentals of OO programming.) The is-consistent-with relationship is
defined by three rules:
@@ -58,12 +58,12 @@
at the root of the class graph. This makes it very similar to
**object**. The difference is that **object** is not consistent with
most types (e.g. you can't use an object() instance where an int is
-expected). IOW both **Any** and **object** mean “any type is allowed”
+expected). IOW both **Any** and **object** mean "any type is allowed"
when used to annotate an argument, but only **Any** can be passed no
matter what type is expected (in essence, **Any** shuts up complaints
from the static checker).
-Here's an example showing how these rules work out in practice:
+Here's an example showing how these rules work out in practice:
Say we have an Employee class, and a subclass Manager:
@@ -72,7 +72,7 @@
Let's say variable e is declared with type Employee:
-- e = Employee() # type: Employee
+- e = Employee() # type: Employee
Now it's okay to assign a Manager instance to e (rule 1):
@@ -81,40 +81,40 @@
It's not okay to assign an Employee instance to a variable declared with
type Manager:
-- m = Manager() # type: Manager
-- m = Employee() # Fails static check
+- m = Manager() # type: Manager
+- m = Employee() # Fails static check
However, suppose we have a variable whose type is **Any**:
-- a = some\_func() # type: Any
+- a = some\_func() # type: Any
Now it's okay to assign a to e (rule 2):
-- e = a # OK
+- e = a # OK
Of course it's also okay to assign e to a (rule 3), but we didn't need
the concept of consistency for that:
-- a = e # OK
+- a = e # OK
Notational conventions
----------------------
-- t1, t2 etc. and u1, u2 etc. are types or classes. Sometimes we write
- ti or tj to refer to “any of t1, t2, etc.”
+- t1, t2 etc. and u1, u2 etc. are types or classes. Sometimes we write
+ ti or tj to refer to "any of t1, t2, etc."
- X, Y etc. are type variables (defined with Var(), see below).
- C, D etc. are classes defined with a class statement.
- x, y etc. are objects or instances.
-- We use the terms type and class interchangeably, and we assume
+- We use the terms type and class interchangeably, and we assume
type(x) is x.\_\_class\_\_.
General rules
-------------
-- Instance-ness is derived from class-ness, e.g. x is an instance of
- t1 if type(x) is a subclass of t1.
+- Instance-ness is derived from class-ness, e.g. x is an instance of
+ t1 if type(x) is a subclass of t1.
- No types defined below (i.e. Any, Union etc.) can be instantiated.
(But non-abstract subclasses of Generic can be.)
- No types defined below can be subclassed, except for Generic and
@@ -136,7 +136,7 @@
Union the result is flattened. (Example: Union[int, Union[float,
str]] == Union[int, float, str].) If ti and tj have a subclass
relationship, the less specific type survives. (Example:
- Union[Employee, Manager] == Union[Employee].) Union[t1] returns just
+ Union[Employee, Manager] == Union[Employee].) Union[t1] returns just
t1. Union[] is illegal, so is Union[()]. Corollary: Union[..., Any,
...] returns Any; Union[..., object, ...] returns object; to cut a
tie, Union[Any, object] == Union[object, Any] == Any.
@@ -154,13 +154,13 @@
argument types t1 etc., and return type tr. The argument list may be
empty (n==0). There is no way to indicate optional or keyword
arguments, nor varargs (we don't need to spell those often enough to
- complicate the syntax — however, Reticulated Python has a useful idea
+ complicate the syntax - however, Reticulated Python has a useful idea
here). This is covariant in the return type, but contravariant in the
- arguments. “Covariant” here means that for two callable types that
+ arguments. "Covariant" here means that for two callable types that
differ only in the return type, the subclass relationship for the
callable types follows that of the return types. (Example:
Callable[[], Manager] is a subclass of Callable[[], Employee].)
- “Contravariant” here means that for two callable types that differ
+ "Contravariant" here means that for two callable types that differ
only in the type of one argument, the subclass relationship for the
callable types goes in the opposite direction as for the argument
types. (Example: Callable[[Employee], None] is a subclass of
@@ -198,13 +198,13 @@
- Type aliases, e.g.
* point = Tuple[float, float]
- * def distance(p: point) -> float: ...
+ * def distance(p: point) -> float: ...
- Forward references via strings, e.g.
* class C:
- + def compare(self, other: “C”) -> int: ...
+ + def compare(self, other: "C") -> int: ...
- If a default of None is specified, the type is implicitly optional, e.g.
@@ -213,11 +213,11 @@
- Don't use dynamic type expressions; use builtins and imported types
only. No 'if'.
- * def display(message: str if WINDOWS else bytes): # NOT OK
+ * def display(message: str if WINDOWS else bytes): # NOT OK
- Type declaration in comments, e.g.
- * x = [] # type: Sequence[int]
+ * x = [] # type: Sequence[int]
- Type declarations using Undefined, e.g.
@@ -237,7 +237,7 @@
the variable name.
- **Y = Var('Y', t1, t2, ...).** Ditto, constrained to t1 etc. Behaves
- like Union[t1, t2, ...] for most purposes, but when used as a type
+ like Union[t1, t2, ...] for most purposes, but when used as a type
variable, subclasses of t1 etc. are replaced by the most-derived base
class among t1 etc.
@@ -249,9 +249,9 @@
- return a if len(a) >= len(b) else b
- * x = longest('a', 'abc') # The inferred type for x is str
+ * x = longest('a', 'abc') # The inferred type for x is str
- * y = longest('a', b'abc') # Fails static type check
+ * y = longest('a', b'abc') # Fails static type check
* In this example, both arguments to longest() must have the same type
(str or bytes), and moreover, even if the arguments are instances of a
@@ -290,7 +290,7 @@
- **class C(Generic[X, Y, ...]):** ... Define a generic class C over type
variables X etc. C itself becomes parameterizable, e.g. C[int, str, ...]
- is a specific class with substitutions X→int etc.
+ is a specific class with substitutions X->int etc.
- TODO: Explain use of generic types in function signatures. E.g.
Sequence[X], Sequence[int], Sequence[Tuple[X, Y, Z]], and mixtures.
@@ -316,7 +316,7 @@
Another reference
-----------------
-Lest mypy gets all the attention, I should mention \ `Reticulated
+Lest mypy gets all the attention, I should mention \ `Reticulated
Python <https://github.com/mvitousek/reticulated>`_ by Michael Vitousek
as an example of a slightly different approach to gradual typing for
Python. It is described in an actual `academic
--
Repository URL: https://hg.python.org/peps
More information about the Python-checkins
mailing list