From 9fd8df6d0c71da4590694559c8d425fb78c1d076 Mon Sep 17 00:00:00 2001 From: Guido van Rossum Date: Fri, 20 May 2016 11:33:13 -0700 Subject: [PATCH] Improve wording on covariance of Type[] (Ivan L, #107). --- pep-0484.txt | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/pep-0484.txt b/pep-0484.txt index c167eaf07..01957bed1 100644 --- a/pep-0484.txt +++ b/pep-0484.txt @@ -372,7 +372,7 @@ takes a single type parameter ``T``. This also makes ``T`` valid as a type within the class body. The ``Generic`` base class uses a metaclass that defines ``__getitem__`` -so that e.g. ``LoggedVar[int]`` is valid as a type:: +so that ``LoggedVar[t]`` is valid as a type:: from typing import Iterable @@ -914,6 +914,7 @@ Note that it is legal to use a union of classes as the parameter for ``Type[]``, as in:: def new_non_team_user(user_class: Type[Union[BasicUser, ProUser]]): + user = new_user(user_class) ... However the actual argument passed in at runtime must still be a @@ -952,8 +953,12 @@ attributes and methods defined by ``type`` (for example, ``__repr__()`` and ``__mro__``). Such a variable can be called with arbitrary arguments, and the return type is ``Any``. -``Type[T]`` should be considered covariant, since for a concrete class -``C``, ``Type[C]`` matches ``C`` and any of its subclasses. +``Type`` is covariant in its parameter, because ``Type[Derived]`` is a +subtype of ``Type[Base]``:: + + def new_pro_user(pro_user_class: Type[ProUser]): + user = new_user(pro_user_class) # OK + ... Version and platform checking