iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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.
This commit is contained in:
Ivan Levkivskyi 2016-10-24 19:29:40 +02:00 committed by Guido van Rossum
parent ae7020c262
commit d309d32728
1 changed files with 4 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
pep-0484.txt
View File

@ -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