-
-
Notifications
You must be signed in to change notification settings - Fork 3k
Make it an error to use a class-attribute type var outside a type #3105
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.
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
Changes from 3 commits
d54708d
fe6eee1
7b8e409
8bfd1a7
7d658c6
54ae7aa
0aa5a70
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -496,12 +496,18 @@ def outer(x: T) -> T: | |
[out] | ||
|
||
[case testClassMemberTypeVarInFunctionBody] | ||
from typing import TypeVar | ||
from typing import TypeVar, List | ||
class C: | ||
T = TypeVar('T', bound=int) | ||
def f(self, x: T) -> T: | ||
A = C.T | ||
return x | ||
L = List[C.T] # a valid type alias | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would doing There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, and good point -- that's not "as a parameter to a type" that's "as a type" How to express "Don't try and use this at runtime"? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess "Is only valid when used as a type or a parameter to a type in a type alias" covers all the bases, but is wicked confusing if I don't already know exactly what it's talking about. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Some time ago we had "... is invalid in runtime context" for subscripted generics. Maybe it is better to say "... can not be used in runtime context, only in type context". There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh! How about
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The second option sounds good. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, rolling with @ilevkivskyi's suggestion for now. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ... as I incur more and more test changes as I can't decide. I think I like how it is now. |
||
l: L = [] | ||
l.append(x) | ||
C.T # E: Type variable "T" is invalid except as a parameter to another type | ||
A = C.T # E: Type variable "T" is invalid except as a parameter to another type | ||
return l[0] | ||
|
||
[builtins fixtures/list.pyi] | ||
|
||
[case testParameterLessGenericAsRestriction] | ||
from typing import Sequence, Iterable, TypeVar | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
small typo: checkmember.py
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
meme-ber. Thank you.