[Python-checkins] peps: Improve wording on covariance of Type[] (Ivan L, #107).

[guido.van.rossum]

https://hg.python.org/peps/rev/8b079eb1ad5d
changeset:   6339:8b079eb1ad5d
user:        Guido van Rossum <guido at python.org>
date:        Fri May 20 11:33:13 2016 -0700
summary:
  Improve wording on covariance of Type[] (Ivan L, #107).

files:
  pep-0484.txt |  11 ++++++++---
  1 files changed, 8 insertions(+), 3 deletions(-)


diff --git a/pep-0484.txt b/pep-0484.txt
--- a/pep-0484.txt
+++ b/pep-0484.txt
@@ -372,7 +372,7 @@
 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 @@
 ``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 @@
 ``__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

-- 
Repository URL: https://hg.python.org/peps