Skip to content

Soften restriction for runtime generics in PEP 484 #120

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Oct 24, 2016
Merged

Soften restriction for runtime generics in PEP 484 #120

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 4 additions & 6 deletions pep-0484.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down