PEP 484: Clarify type erasure and instantiation of concrete collections #193
Conversation
pep-0484.txt
Outdated
| common practice in languages with generics (e.g. Java, TypeScript). | ||
|
|
||
| Generic versions of concrete collections (except for built-in classes) | ||
| could be instantiated:: |
| -- ``IntNode`` and ``StrNode`` are distinguishable class objects, but | ||
| 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). |
There was a problem hiding this comment.
The previous paragraphs suggest that you have to create a type alias (e.g. IntNode) but that's no longer necessary (since it's no longer as slow). Maybe you can update that while you're at it? I'd still recommend using a type alias (since it's clearer and still a tiny bit faster) but it's not strictly necessary.
pep-0484.txt
Outdated
| data = DefaultDict[int, bytes]() | ||
|
|
||
| Note that one should not confuse static types and runtime classes. | ||
| Type is still erased in this case and the above expression is |
pep-0484.txt
Outdated
| record the distinction. This behavior is called "type erasure"; it is | ||
| common practice in languages with generics (e.g. Java, TypeScript). | ||
|
|
||
| Generic versions of concrete collections (except for built-in classes) |
There was a problem hiding this comment.
"built-in classes" is a little ambiguous. I think it refers to exactly List, Set and Dict, right? If so, I would just list those. Also mention that user-defined subclasses thereof can be instantiated.
(Tuple is excluded for a different reason, it's not a regular class.)
|
@gvanrossum Thank you for review! I have rewritten the part on type aliases as you proposed and listed explicitly types that can and cannot be instantiated. |
pep-0484.txt
Outdated
|
|
||
| Note that the runtime type (class) of ``p`` and ``q`` is still just ``Node`` | ||
| -- ``Node[int]`` and ``Node[str]`` are distinguishable class objects, but | ||
| the type (class) of the objects created by instantiating them doesn't |
There was a problem hiding this comment.
I'd use "runtime class" rather than "type (class)" here.
pep-0484.txt
Outdated
|
|
||
| Generic versions of abstract collections like ``Mapping`` or ``Sequence`` | ||
| and generic versions of built-in classes -- ``List``, ``Dict``, ``Set``, | ||
| and ``FrozenSet`` cannot be instantiated. However, user-defined subclasses |
There was a problem hiding this comment.
Need another "--" before "cannot". Also perhaps add "concrete" before "user-defined"?
|
@gvanrossum I fixed the remaining things in a new commit. |
|
Thanks! Still need to hold back reviewing your other stuff, sorry. |
|
No problem, take your time. (I will probably produce more stuff in the meantime). |
3 participants
@gvanrossum Could you please take a look at this? (when you have time, this is not urgent)
Fixes python/typing#367