From d309d327286da385dd4fabb6525677c6de484de2 Mon Sep 17 00:00:00 2001 From: Ivan Levkivskyi Date: Mon, 24 Oct 2016 19:29:40 +0200 Subject: [PATCH] Soften restriction for runtime generics in PEP 484 (#120) Fixes https://github.com/python/typing/issues/303. See also https://github.com/python/mypy/pull/2302 (which removes the restriction from mypy). As a motivation, in Python one always can substitute expressions, so that if ``IntNode = Node[int]; IntNode()`` works, then it is reasonable to also allow ``Node[int]``, but say that the first way is preferred. --- pep-0484.txt | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/pep-0484.txt b/pep-0484.txt index 1d826eb0e..df7ab225a 100644 --- a/pep-0484.txt +++ b/pep-0484.txt @@ -600,12 +600,10 @@ the type (class) of the objects created by instantiating them doesn't record the distinction. This behavior is called "type erasure"; it is common practice in languages with generics (e.g. Java, TypeScript). -You cannot use the subscripted class (e.g. ``Node[int]``) directly in -an expression -- you must define a type alias. (This restriction -exists because creating the subscripted class, e.g. ``Node[int]``, is -an expensive operation -- usually many times as expensive as -constructing an instance of it. Using a type alias is also more -readable.) +It is not recommended to use the subscripted class (e.g. ``Node[int]``) +directly in an expression -- using a type alias instead is preferred. +(First, creating the subscripted class, e.g. ``Node[int]``, has a runtime +cost. Second, using a type alias is more readable.) Arbitrary generic types as base classes