Update generic class attribute and type variable usage #239
Conversation
|
Hello, and thanks for your contribution! I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA). Unfortunately we couldn't find an account corresponding to your GitHub username on bugs.python.org (b.p.o) to verify you have signed the CLA. This is necessary for legal reasons before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue. Thanks again to your contribution and we look forward to looking at it! |
pep-0484.txt
Outdated
| p.x # Ok | ||
| Node[int]().x # Ok | ||
|
|
||
| In addition, ``ClassVar`` cannot be parametrized. |
There was a problem hiding this comment.
Oh I thought so too, but I searched the text and found it uses parametrized. Now I searched again, and I found it uses both, 2 times each (not counting my own usage) 😆 I guess I should have checked dictionary instead ...
pep-0484.txt
Outdated
| @@ -610,6 +611,21 @@ the runtime 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). | |||
|
|
|||
| Class attribute of a generic class can be looked up only through the instance | |||
There was a problem hiding this comment.
"attributes" is probably what you meant here.
There was a problem hiding this comment.
Hmm, I am not sure.
Somehow I interpret instance attribute as referring to the physical object stored on an instance, and of course if there is one, we can't actually refer to the class attribute at all.
I really meant "by using the instance", but if this is confusing, I can try to rephrase.
|
I added another clarification: that |
pkch
changed the title
|
The last commit is as discussed in python/mypy#3148 (comment) |
|
@gvanrossum mentioning you just in case (this is not urgent). |
pep-0484.txt
Outdated
| @@ -610,6 +612,24 @@ the runtime 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). | |||
|
|
|||
| Using generic classes (parameterized or not) to access attributes will result | |||
| in both type check failure and runtime error. Outside the class definition | |||
There was a problem hiding this comment.
and runtime error.
Is it really a runtime error for examples below? I just tried it and all worked fine at runtime.
There was a problem hiding this comment.
Ah right. I misunderstood your comment that it's fixed in typing. I thought you meant it now causes runtime error, but actually what you meant is that it no longer returns different values depending on how it's accessed.
pep-0484.txt
Outdated
| Node[int]().x # Ok (evaluates to None) | ||
| p.x = 1 # Ok, but assigning to instance attribute | ||
|
|
||
| In addition, ``ClassVar`` cannot be parameterized. |
There was a problem hiding this comment.
ClassVar is not a part of PEP 484.
pep-0484.txt
Outdated
| <type> itself cannot be parametrized by type variables). This means that an | ||
| actual type substituted (explicitly or implicitly) for the type variable must | ||
| be a subtype of the boundary type. A common example is the definition of a | ||
| Comparable type that works well enough to catch the most common errors:: |
There was a problem hiding this comment.
While yo at it, can you please make this
``Comparable``
i.e. use backquotes.
|
Thanks! |
|
@pkch Would you like to also make a small PR updating the PEP 526 and saying that things like |
Clarification based on python/mypy#2878