Skip to content

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.

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 7 commits into from
Apr 3, 2017
Merged

Make it an error to use a class-attribute type var outside a type #3105

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
d54708d
Make it an error to use a class-attribute type var outside a type
sixolet Apr 1, 2017
fe6eee1
Fix the error message to handle more cases
sixolet Apr 1, 2017
7b8e409
oops accidentally changed a file
sixolet Apr 1, 2017
8bfd1a7
Typo fix
sixolet Apr 1, 2017
7d658c6
more checking things in tests
sixolet Apr 1, 2017
54ae7aa
Change error message
sixolet Apr 1, 2017
0aa5a70
Change error message
sixolet Apr 1, 2017
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
4 changes: 3 additions & 1 deletion mypy/checkmember.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -406,7 +406,9 @@ def analyze_class_attribute_access(itype: Instance,
return AnyType()

if isinstance(node.node, TypeVarExpr):
return TypeVarType(node.tvar_def, node.tvar_def.line, node.tvar_def.column)
msg.fail('Type variable "{}.{}" cannot be used as an expression'.format(
itype.type.name(), name), context)
return AnyType()

if isinstance(node.node, TypeInfo):
return type_object_type(node.node, builtin_type)
Expand Down
3 changes: 3 additions & 0 deletions mypy/typeanal.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -43,6 +43,9 @@ def analyze_type_alias(node: Expression,
# that we don't support straight string literals as type aliases
# (only string literals within index expressions).
if isinstance(node, RefExpr):
# Note that this misses the case where someone tried to use a
# class-referenced type variable as a type alias. It's easier to catch
# that one in checkmember.py
if node.kind == UNBOUND_TVAR or node.kind == BOUND_TVAR:
fail_func('Type variable "{}" is invalid as target for type alias'.format(
node.fullname), node)
Expand Down
14 changes: 11 additions & 3 deletions test-data/unit/check-typevar-values.test
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -496,12 +496,20 @@ 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would doing y: C.T = x be valid?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The 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"?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The 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.

Copy link
Member

Choose a reason for hiding this comment

The 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".

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh! How about

  • "Type variable 'C.T' is not a valid expression"
  • "Type variable 'C.T' cannot be used as an expression"
    ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The second option sounds good.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, rolling with @ilevkivskyi's suggestion for now.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The 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 = []
reveal_type(l) # E: Revealed type is 'builtins.list[T`-1]'
y: C.T = x
l.append(x)
C.T # E: Type variable "C.T" cannot be used as an expression
A = C.T # E: Type variable "C.T" cannot be used as an expression
return l[0]

[builtins fixtures/list.pyi]

[case testParameterLessGenericAsRestriction]
from typing import Sequence, Iterable, TypeVar
Expand Down