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.

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

Conversation

sixolet
Copy link
Collaborator

@sixolet sixolet commented Apr 1, 2017

Previously, e9d28a0 fixed a crash when you tried to access a class-attribute
type variable. The test in that commit involved assigning a variable the value
of the typevar. It resulted in no crash, but rather treating the variable as
being an instance of the type the typevar bound to, later, which is incorrect.

For example (and this is the test defined in e9d28a0, modified)

 from typing import TypeVar
 class C:
     T = TypeVar('T', int)
     def f(self, x: T) -> T:
         A = C.T
         reveal_type(A)  # E: revealed type is "T`-1"
         return x

Instead, this PR treats such an assignment as an error -- any reference to such a classvar tvar outside trying to construct a type out of it is an error.

Also test a correct alias with the typevar access method in question -- it
works.

sixolet added 3 commits April 1, 2017 01:46
Previously, e9d28a0 fixed a crash when you tried to access a class-attribute
type variable. The test in that commit involved assigning a variable the value
of the typevar. It resulted in no crash, but rather treating the variable as
being an instance of the type the typevar bound to, later, which is incorrect.

Instead, this PR treats such an assignment as an error, and gives you the same
message as when you try to alias a typevar directly.

Also test a *correct* alias with the typevar access method in question -- it
works.
mypy/typeanal.py Outdated
@@ -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 checkmemeber.py
Copy link
Member

Choose a reason for hiding this comment

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

small typo: checkmember.py

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

meme-ber. Thank you.

@sixolet
Copy link
Collaborator Author

sixolet commented Apr 1, 2017

I'm not exactly sure about the wording of the error here, suggestions welcome.

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.

@JukkaL
Copy link
Collaborator

JukkaL commented Apr 3, 2017

Thanks for the PR! LGTM

@JukkaL JukkaL merged commit 61cdbf3 into python:master Apr 3, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants