From e3afb56306bc47bb5780468abe937c3df49ab9bf Mon Sep 17 00:00:00 2001 From: Ivan Levkivskyi Date: Fri, 6 May 2016 22:19:35 +0200 Subject: [PATCH 1/2] Be more precise about types vs. classes Also remove the mention of issubclass in the description of Union, and add a note about this for other special constructs. --- pep-0484.txt | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/pep-0484.txt b/pep-0484.txt index 3769944e..4c5a18ea 100644 --- a/pep-0484.txt +++ b/pep-0484.txt @@ -587,7 +587,7 @@ Type variables with an upper bound A type variable may specify an upper bound using ``bound=``. This means that an actual type substituted (explicitly or implictly) -for the type variable must be a subclass of the boundary type. A +for the type variable must be a subtype of the boundary type. A common example is the definition of a Comparable type that works well enough to catch the most common errors:: @@ -618,7 +618,7 @@ concept, F-bounded polymorphism. We may revisit this in the future.) An upper bound cannot be combined with type constraints (as in used ``AnyStr``, see the example earlier); type constraints cause the inferred type to be _exactly_ one of the constraint types, while an -upper bound just requires that the actual type is a subclass of the +upper bound just requires that the actual type is a subtype of the boundary type. @@ -819,9 +819,11 @@ Example:: e = [e] ... -A type factored by ``Union[T1, T2, ...]`` responds ``True`` to -``issubclass`` checks for ``T1`` and any of its subtypes, ``T2`` and -any of its subtypes, and so on. +A type factored by ``Union[T1, T2, ...]`` is compatible with +``T1`` and any of its subtypes, ``T2`` and +any of its subtypes, and so on. In other words, values of all types +``T1``, ``T2``, etc., and their subtypes are acceptable for +an argument annotated by ``Union[T1, T2, ...]``. One common case of union types are *optional* types. By default, ``None`` is an invalid value for any type, unless a default value of @@ -1294,6 +1296,11 @@ collections (e.g. ``List``), types representing generic collection ABCs (e.g. ``Sequence``), and a small collection of convenience definitions. +Note that special type constructs, such as ``Any``, ``TypeVar``, +``Union``, and ``Generic`` are only supported in the type annotation +context and will raise ``TypeError`` if appear in ``isinstance`` +or ``issubclass``. + Fundamental building blocks: * Any, used as ``def get(key: str) -> Any: ...`` From 6025216640d9fa1e8962fd6d13a170e69783afa2 Mon Sep 17 00:00:00 2001 From: Ivan Levkivskyi Date: Sat, 7 May 2016 00:48:41 +0200 Subject: [PATCH 2/2] Corresctions in respond to comments --- pep-0484.txt | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/pep-0484.txt b/pep-0484.txt index 4c5a18ea..b0db72f8 100644 --- a/pep-0484.txt +++ b/pep-0484.txt @@ -819,11 +819,10 @@ Example:: e = [e] ... -A type factored by ``Union[T1, T2, ...]`` is compatible with -``T1`` and any of its subtypes, ``T2`` and -any of its subtypes, and so on. In other words, values of all types -``T1``, ``T2``, etc., and their subtypes are acceptable for -an argument annotated by ``Union[T1, T2, ...]``. +A type factored by ``Union[T1, T2, ...]`` is a supertype +of all types ``T1``, ``T2``, etc., so that a value that +is a member of one of these types is acceptable for an argument +annotated by ``Union[T1, T2, ...]``. One common case of union types are *optional* types. By default, ``None`` is an invalid value for any type, unless a default value of @@ -1296,10 +1295,11 @@ collections (e.g. ``List``), types representing generic collection ABCs (e.g. ``Sequence``), and a small collection of convenience definitions. -Note that special type constructs, such as ``Any``, ``TypeVar``, -``Union``, and ``Generic`` are only supported in the type annotation -context and will raise ``TypeError`` if appear in ``isinstance`` -or ``issubclass``. +Note that special type constructs, such as ``Any``, ``Union``, +and type variables defined using ``TypeVar`` are only supported +in the type annotation context, and ``Generic`` may only be used +as a base class. All of these will raise ``TypeError`` if appear +in ``isinstance`` or ``issubclass``. Fundamental building blocks: