Implement ClassVar semantics (fixes #2771) #2873

miedzinski · 2017-02-15T22:53:54Z

Support ClassVar annotations

Implements ClassVar introduced in PEP 526. Resolves #2771, #2879.

Support annotating class attributes with ClassVar[...].
Prohibit ClassVar annotations outside class bodies (regular variable annotations, function and method signatures).
Prohibit assignments to class variables accessed from instances (including assignments on self).
Add checks for overriding class variables with instance variables and vice versa when subclassing.
Prohibit ClassVars nested inside other types.
Add is_classvar flag to Var.
Add nesting_level attribute to TypeAnalyser and use it inside helper methods anal_type and anal_array. Move analyzing implicit TupleTypes from SemanticAnalyzer to TypeAnalyser.
Analyze ClassVar[T] as T and bare ClassVar as Any.
Prohibit generic ClassVars and accessing generic instance variables via class (see Generic class atributes aren't fully instantiated #2878 comments). Add types.get_type_vars helper, which returns all type variables present in analyzed type, similar to TypeAnalyser.get_type_var_names.

ilevkivskyi · 2017-02-15T23:20:29Z

mypy/checkexpr.py

@@ -2218,6 +2218,8 @@ def bool_type(self) -> Instance:
        return self.named_type('builtins.bool')

    def narrow_type_from_binder(self, expr: Expression, known_type: Type) -> Type:
+        if isinstance(known_type, ClassVarType):
+            known_type = known_type.item


This indeed looks strange, and probably would be not necessary if class variables would be implemented as flags for types or Var nodes.

ilevkivskyi · 2017-02-15T23:25:35Z

mypy/subtypes.py

@@ -52,6 +53,9 @@ def is_subtype(left: Type, right: Type,
        return any(is_subtype(left, item, type_parameter_checker,
                              ignore_pos_arg_names=ignore_pos_arg_names)
                   for item in right.items)
+    elif isinstance(right, ClassVarType):
+        return is_subtype(left, right.item, type_parameter_checker,
+                          ignore_pos_arg_names=ignore_pos_arg_names)


I don't think ClassVar represents actually a new type, so that it should not appear here, otherwise you would need to implement also meet_types, join_types, etc. ClassVar is rather an "access modifier" for a class member.

ilevkivskyi · 2017-02-15T23:29:58Z

mypy/checker.py

@@ -1575,6 +1575,9 @@ def check_member_assignment(self, instance_type: Type, attribute_type: Type,

        Return the inferred rvalue_type and whether to infer anything about the attribute type
        """
+        if isinstance(instance_type, Instance) and isinstance(attribute_type, ClassVarType):
+            self.msg.fail("Illegal assignment to class variable", context)
+


I believe this code should rather appear in analyze_member_access (there is also a special flag is_lvalue to indicate that an assignment to a member is being analysed rather that reading from it).

ilevkivskyi · 2017-02-15T23:31:07Z

mypy/typeanal.py

@@ -148,6 +148,12 @@ def visit_unbound_type(self, t: UnboundType) -> Type:
                items = self.anal_array(t.args)
                item = items[0]
                return TypeType(item, line=t.line)
+            elif fullname == 'typing.ClassVar':
+                if len(t.args) != 1:


I think a bare ClassVar should be also allowed meaning ClassVar[Any]

ilevkivskyi · 2017-02-15T23:35:06Z

mypy/types.py

@@ -1189,6 +1189,29 @@ def deserialize(cls, data: JsonDict) -> 'TypeType':
        return TypeType(Type.deserialize(data['item']))


+class ClassVarType(Type):


As I already mentioned, I think this should be rather a flag in Type base class or in the Var symbol node (maybe is_classvar flag in some analogy to is_classmethod).

ilevkivskyi · 2017-02-15T23:42:49Z

test-data/unit/check-classvar.test

+y = A.x
+reveal_type(y)
+[out]
+main:5: error: Revealed type is 'builtins.int'


I think more tests are needed here, some ideas:

More tests on accessing class vars (through instances, subclasses, and instances of subclasses)

Class vars with complex types: user defined types, generic collections

Test behaviour of class vars with type variables in user defined generic classes

Check correct access and inference for the above point

Check more overriding options: overriding by an instance variable in subclass, and by assigning to an instance of subclass (I believe both should be errors)

Test behaviour on attempts to define and/or override class vars inside method bodies.

Maybe multiple inheritance

Add also few tests that combine more than one of the above ideas

ilevkivskyi · 2017-02-15T23:49:32Z

Thank you for working on this! Here are some comments. I think the two major are:

more tests are needed
class variables should be implemented as flags (access modifiers for members) rather than a new kind of types.

miedzinski · 2017-02-15T23:57:13Z

Indeed, is_classvar in Var was my first attempt at it and I can agree it makes more sense. Unfortunately, I couldn't work out where the semantic analysis should be done - semanal.py or checker.py, or somewhere else? I know marking Vars with proper flag should be done somewhere around visit_assignment_stmt in SemanticAnalyzer (that's when mypy first sees class atributtes, right?), but I can't feel where it's best to do actual checks.

ilevkivskyi · 2017-02-16T00:12:02Z

I couldn't work out where the semantic analysis should be done - semanal.py or checker.py, or somewhere else?

It should be done in semanal.py, checker.py is already the type checking stage. Most probably in visit_assignment_stmt after lvalue is analysed (so that corresponding Var node is already created and set in appropriate symbol table).

There are also some other places you should pay attention, in particular analyze_member_acces in checkmember.py that I mentioned in review.

EDIT: corrected file name

miedzinski · 2017-02-16T00:19:04Z

Great, thanks! This is the approach I tried first, but somehow got convinced the *checking* should be done in typechecker (despite that ClassVar is not really a type) and ended up with ClassVarType and hacks around it.

elazarg · 2017-02-16T09:03:51Z

Theoretically, ClassVar in a class A should be a field in the metaclass of A (which is never the declared metaclass but a "ghost" metaclass created for A which inherits from the declared/analyzed metaclass).
This way there is no special treatment after the semantic analysis.

Similarly this should be the case for @classmethod, except the runtime behavior of @classmethod is somewhat incompatible since it is not implemented this way in CPython.

In other words, if we'll get Type[T] for classes T refer to dedicated TypeInfo for the ghost metaclass, this feature should (hopefully) be trivial to implement: add a variable to the TypeInfo.

miedzinski · 2017-02-16T20:41:14Z

@ilevkivskyi, removed ClassVarType, introduced Var.is_classvar and added more tests. I hope it's better now.

miedzinski · 2017-02-16T22:13:28Z

What's not done (and I'd rather postpone to another PR):

assignments with multiple lvalues, like

class A:
    x, y = 1, 2  # type: ClassVar[int], ClassVar[int]
    [a, b, *c] = ['a', 'b']  # type: List[ClassVar]

disallowing ClassVars in function/method signatures

I think basic cases of ClassVars in signatures could be easily checked in SemanticAnalyzer.analyze_function, right before call to anal_type on function type, but with signatures like def f(x: Callable[[ClassVar], int]) -> None (with ClassVar hidden inside another type) it is less trivial.

ilevkivskyi

Thanks! This looks better, I still have some comments. In addition, there are three important things that should be done in this PR:

Prohibit definition of class vars inside methods, i.e. x: ClassVar[int] should fail inside methods (probably using .is_func_scope())
Prohibit class vars in function signatures (as you mentioned)
In general ClassVar should be allowed only as an "outermost" type for simple assignments, things like Union[ClassVar[T], int] are invalid (and will actually fail at runtime). This probably should be done in typeanal.py

Everything else probably could be done later in a separate PR

ilevkivskyi · 2017-02-17T08:45:24Z

mypy/checkmember.py

@@ -268,6 +268,8 @@ def analyze_var(name: str, var: Var, itype: Instance, info: TypeInfo, node: Cont
        if is_lvalue and var.is_property and not var.is_settable_property:
            # TODO allow setting attributes in subclass (although it is probably an error)
            msg.read_only_property(name, info, node)
+        if is_lvalue and var.is_classvar:
+            msg.cant_assign_to_classvar(node)


This looks surprisingly simple, but maybe more corner cases will be necessary for more tests, see below

It does, but I think it works. There are tests with subclasses, callables, Type type and everything passes.

ilevkivskyi · 2017-02-17T09:11:49Z

mypy/semanal.py

+            return False
+        if self.is_class_scope() or not isinstance(lvalue.node, Var):
+            node = cast(Var, lvalue.node)
+            node.is_classvar = True


This looks wrong to me: in this branch lvalue.node is not an instance of Var, why do you set the .is_classvar flag on something that could be not a Var?

Indeed, that was wrong. I had if statements written a bit different at first and didn't fully apply De Morgan's law there. And because mypy was complaining there (and I didn't see anything wrong in it...), I've added cast.

ilevkivskyi · 2017-02-17T09:14:43Z

mypy/semanal.py

+            return False
+
+    def check_classvar_override(self, node: Var, is_classvar: bool) -> None:
+        name = node.name()


I think this should be deferred to a later stage and checked in checker.py (probably in visit_assignment_stmt)

ilevkivskyi · 2017-02-17T09:16:18Z

mypy/typeanal.py

+                if len(t.args) == 0:
+                    return AnyType(line=t.line)
+                if len(t.args) != 1:
+                    self.fail('ClassVar[...] must have exactly one type argument', t)


The error message could be misleading, change it to "... at most one type argument"

ilevkivskyi · 2017-02-17T09:18:14Z

test-data/unit/check-classvar.test

+from typing import ClassVar
+class A:
+    x = 1  # type: ClassVar[int]
+A().x


Use reveal_type here to show that the type is correctly read (i.e. int in this case).

ilevkivskyi · 2017-02-17T09:25:49Z

test-data/unit/check-classvar.test

+    pass
+class B:
+    x = A()  # type: ClassVar[A]
+


Add tests where type inside ClassVar is more complex, like List[int], Union[int, str] etc. And check:

class C: x: ClassVar[List[int]] C()[0] = 1 # This should probably succeed C()[0] = 's' # This fails

I have resorted to using list.append, because indexed assignment didn't work in unit tests (even without ClassVar).

ilevkivskyi · 2017-02-17T09:29:00Z

test-data/unit/check-classvar.test

+    x = None  # type: ClassVar[A]
+C.x = B()
+[out]
+main:8: error: Incompatible types in assignment (expression has type "B", variable has type "A")


Check that this succeeds if B is a subclass of A, also check that you can override one classvar with another compatible in a subclass,:

class A: pass class B(A): pass class C: x = None # type: ClassVar[A] class D(C): x = None # type: ClassVar[B] # This should be allowed

ilevkivskyi · 2017-02-17T09:33:40Z

test-data/unit/semanal-classvar.test

+    x = 1  # type: int
+class B(A):
+    x = 2  # type: ClassVar[int]
+[out]


This test looks identical to the previous one.

Fixed. :) I've meant to test the "opposite" case, where normal attribute is overridden with ClassVar.

ilevkivskyi · 2017-02-17T09:40:55Z

test-data/unit/semanal-classvar.test

+class A:
+    x = None  # type: ClassVar[T]
+[out]
+main:4: error: Invalid type "__main__.T"


Tests involving generic classes are still missing, for example like these:

T = TypeVar('T') class A(Generic[T]): x = None # type: ClassVar[T] reveal_type(A[int].x) # this should be int class B(Generic[T]): x = None # type: ClassVar[List[T]] B[int].x[0] = 'abc' # This should fail

etc.

miedzinski · 2017-02-17T15:14:57Z

Again, added more tests. :) I will move overriding checks to type checker and test cases for ClassVar in function signatures later.

Prohibit definition of class vars inside methods, i.e. x: ClassVar[int] should fail inside methods (probably using .is_func_scope())

This is already done; ClassVar can be defined only in class scope. There are tests for ClassVars in module scope, class scope (class attributes), function scope and in methods. But I've found it is possible to define instance variable as ClassVar when accessing self, like

class A:
    def __init__(self) -> None:
        self.x = None  # type: ClassVar

I'll fix it and add test case for this.

Prohibit class vars in function signatures (as you mentioned)

Could you guide me a bit with this then? Like I said, this could be done in SemanticAnalyzer.analyze_function, before call to anal_type (after that, information about ClassVars is lost). However, I can't see how can I detect ClassVar in more complex types like Callable[[ClassVar], None] or Union[int, List[ClassVar[str]] without reinventing the wheel - I mean there must be some helpers already defined for cases like this, right? The problem is that at this point most types are not yet analyzed (UnboundType).

In general ClassVar should be allowed only as an "outermost" type for simple assignments, things like Union[ClassVar[T], int] are invalid (and will actually fail at runtime). This probably should be done in typeanal.py

I can totally agree about Union[ClassVar[T], int], but

class A:
    x, y = 1, 2  # type: ClassVar[int], ClassVar[int]
    [a, b, *c] = ['a', 'b']  # type: List[ClassVar]

is valid Python and produces A.x: int, A.y: int, A.a: Any, A.b: Any, A.c: List. I know this code is weird, but theoretically one could write something like this and expect all these attributes to be ClassVars. Moreover, there is nothing in PEP 526 that forbids cases like this; I think it should work.

class A:
    x: Union[ClassVar[int], ClassVar[str]]

could also work, but of course we should recommend writing x: ClassVar[Union[int, str]].

ilevkivskyi · 2017-02-17T16:34:38Z

test-data/unit/semanal-classvar.test

+    x = 1  # type: ClassVar[int]
+class B(A):
+    x = 2  # type: int
+[out]


Now this tests repeats testOverrideWithNormalAttribute

ilevkivskyi · 2017-02-17T16:57:23Z

Thank you for working on this! Here is some response to your questions:

Could you guide me a bit with this then? Like I said, this could be done in SemanticAnalyzer.analyze_function, before call to anal_type (after that, information about ClassVars is lost). However, I can't see how can I detect ClassVar in more complex types like Callable[[ClassVar], None] or Union[int, List[ClassVar[str]] without reinventing the wheel

You don't need to, if you will only allow ClassVar as the outermost "type", then you could check only for the name of unbound type.

I can totally agree about Union[ClassVar[T], int], but

class A:
    x, y = 1, 2  # type: ClassVar[int], ClassVar[int]
    [a, b, *c] = ['a', 'b']  # type: List[ClassVar]

I propose not to allow the syntax in last line now. We don't even know yet how people will use the ClassVar, and whether the above feature will be needed. If someone will ask for this and when it will be added, then we could easily add an exception allowing List (and/or Tuple) one level outside ClassVar.

class A:
    x: Union[ClassVar[int], ClassVar[str]]

could also work, but of course we should recommend writing x: ClassVar[Union[int, str]].

I think this should not be allowed. First of all, "there should be only one way to do it" :-), second, we should not allow something that may make people think ClassVar is a proper type. We should emphasize that it is just an "access modifier".

I will move overriding checks to type checker and test cases for ClassVar in function signatures later.

I am looking forward for this and for fix for self.x. I will make then another (hopefully last) round of review.

ilevkivskyi · 2017-02-17T17:16:58Z

test-data/unit/check-classvar.test

+[out]
+main:5: error: Revealed type is 'builtins.list[builtins.int*]'
+main:6: error: Argument 1 to "append" of "list" has incompatible type "str"; expected "T"
+


Hm... This error message looks suspicious, it should say "int" instead of "T".
I checked, this is the same without ClassVar, but since we are introducing this feature (class variables), it would be nice to fix this. I guess it is something to do with add_class_tvars in checkmember.py only considering Callable and Overloaded (presumably for @classmethods), but now that we are going to have arbitrary class variables, we should also consider other options (Instance, UnionType, TypeType, etc.) I think this is important because it is something to do with the "core" of new feature.

And could you please add a test with correct assignment, i.e. A[int].x.append(42).

@miedzinski Jukka proposes, and I agree with him, that generic class variables should be prohibited. So that things like x = None # type: ClassVar[List[T]] should be flagged as errors. It is quite easy to check, there is a function in typeanal.py, get_type_var_names that returns all type variables in an analyzed type (even deeply nested ones). You should make an error if this function returns a non-empty list for something wrapped in ClassVar

ilevkivskyi · 2017-02-17T17:35:47Z

Sorry, one last thing, could you please also add tests involving import between modules (accessing class var on a class defined in another module), also in check-incremental.test to test the correct serialization of Var nodes with is_classvar == True.

miedzinski · 2017-02-17T20:10:01Z

I've made TypeAnalyser aware of it's nesting level, which is (at least for now) only used for finding invalid ClassVar usages. I hope it resolves the issue with ClassVars inside other types or in function signatures. Additionally, I've simplified SemanticAnalyzer.anal_type a bit.

TODO:

issue with self
tests for classes defined in another module
tests for Var.is_classvar serialization

Regarding generics: I can do this, but in another PR. It's not directly related to ClassVar.

T = TypeVar('T')
class A(Generic[T]):
    x = None  # type: List[T]

A[int].x.append(0)

Right now this fails with error: Argument 1 to "append" of "list" has incompatible type "int"; expected "T" - there is definitely something wrong with generics. Adding A[int].x.append(0) statement to ClassVar tests will make them fail, but it's not because of ClassVar. I've opened new issue - #2878.

miedzinski · 2017-02-17T21:45:10Z

@ilevkivskyi, done.

ilevkivskyi

OK, thank you, this is almost ready! Just few more minor comments.

ilevkivskyi · 2017-02-18T09:33:57Z

mypy/semanal.py

-                                         self.builtin_type('builtins.tuple'), t.line)
-                    items = [self.anal_type(item, True)
-                             for item in t.items]
-                    return TupleType(items, self.builtin_type('builtins.tuple'), t.line)


Is this change really necessary? I am asking for two reasons:

This looks unrelated to class variables

The transformation you made is actually not equivalent, this code returns more precise type on failure (TupleType with corresponding number of Anys as items, instead of just plain AnyType() in typeanal.py code)

My bad. I've restored old behaviour, although in TypeAnalyser. This is needed if we want to fail on

class A: x, y = None, None # type: ClassVar, ClassVar

Since I've removed the test for this we could allow this, but these variables wouldn't get is_classvar flag. I would keep it as is.

ilevkivskyi · 2017-02-18T09:36:55Z

mypy/semanal.py

@@ -2159,6 +2148,29 @@ def build_typeddict_typeinfo(self, name: str, items: List[str],

        return info

+    def check_classvar(self, s: AssignmentStmt) -> None:
+        lvalue = s.lvalues[0]
+        if len(s.lvalues) != 1 or not isinstance(lvalue, (NameExpr, MemberExpr)):


You can just use RefExpr instead of (NameExpr, MemberExpr)

ilevkivskyi · 2017-02-18T09:43:03Z

mypy/typeanal.py

+                if len(t.args) != 1:
+                    self.fail('ClassVar[...] must have at most one type argument', t)
+                    return AnyType()
+                items = self.anal_array(t.args)


I think it would be cleaner if you just return self.anal_nested(t.args[0])

ilevkivskyi · 2017-02-18T09:53:20Z

test-data/unit/check-classvar.test

+    x = 1  # type: ClassVar[int]
+A().x = 2
+[out]
+main:4: error: Illegal assignment to class variable


You use too general error messages that might be not very helpful for a user trying to figure out what is wrong. You could use: 'Can not assign to class variable "x" via instance'.

ilevkivskyi · 2017-02-18T09:58:17Z

test-data/unit/check-classvar.test

+class B(A):
+    x = 2  # type: int
+[out]
+main:5: error: Invalid class attribute definition (previously declared on base class "A")


This error message is also too generic. I would propose two separate messages:

'Cannot override class variable (previously declared on base class "A") with instance variable'

'Cannot override instance variable (previously declared on base class "A") with class variable'

ilevkivskyi · 2017-02-18T10:06:09Z

test-data/unit/semanal-classvar.test

+class A:
+    x, y = None, None  # type: ClassVar, ClassVar
+[out]
+main:3: error: Invalid ClassVar definition


Although this is not allowed now, I don't think we need to explicitly test this, maybe we will allow this in the future.

ilevkivskyi · 2017-02-18T10:08:52Z

test-data/unit/semanal-classvar.test

+from typing import ClassVar
+def f(x: str, y: ClassVar) -> None: pass
+[out]
+main:2: error: Invalid ClassVar definition


I would like to see one more test with a method, like this

class C: def meth(x: ClassVar[int]) -> None: ... # Error

also we need to prohibit ClassVar in for and with statements inside class, like this:

class D: for i in range(10): # type: ClassVar[int] # Error here

ilevkivskyi · 2017-02-18T10:14:26Z

test-data/unit/semanal-classvar.test

+class B:
+    x = None  # type: A[ClassVar]
+[out]
+main:5: error: Invalid ClassVar definition


I would like to also have two separate error messages instead of "Invalid ClassVar definition":

"ClassVar could be only used for assignments in class body"

"Invalid type: ClassVar nested inside other type"

miedzinski · 2017-02-18T14:16:54Z

@ilevkivskyi, done. Thanks for suggesting new error messages - I wasn't especially proud of them, but it definitely isn't my strong side. :)

ilevkivskyi · 2017-02-19T15:59:48Z

test-data/unit/semanal-classvar.test

+from typing import ClassVar
+def f() -> ClassVar: pass
+[out]
+main:2: error: Invalid type: ClassVar nested inside other type


I have one last comment, I would really prefer to see the other error "ClassVar can only be used for assignments in class body" in these three tests. I understand why it behaves like this, but maybe you could play a bit with visit_func_def and typeanal.py to tweak this?

ilevkivskyi · 2017-02-19T16:03:07Z

@miedzinski Also I would recommend you to update the PR description and add there a brief summary of what you implement here, and how you do this (the current description is too much outdated).

miedzinski · 2017-02-19T18:28:48Z

@ilevkivskyi, done. In case of ClassVars inside function signatures, but hidden in other types mypy will still report error: Invalid type: ClassVar nested inside other type. I've decided not to bother; I don't think it's confusing at all.

ilevkivskyi · 2017-02-19T18:36:41Z

In case of ClassVars inside function signatures, but hidden in other types mypy will still report error: Invalid type: ClassVar nested inside other type

Thanks! This is exactly what I wanted. The PR now LGTM.

miedzinski · 2017-02-22T17:31:30Z

@ilevkivskyi, done. I have added another helper - TypeAnalyser.get_type_vars - because the method you've mentioned seems to be suited for type aliases. They are pretty similar though.

I have updated the PR description. I suppose this is not enough to close #2878, right?

ilevkivskyi · 2017-02-24T23:15:45Z

I suppose this is not enough to close #2878, right?

I think you could follow this idea #2878 (comment) and use your function get_type_vars to prohibit access via class to instance variables with types that contain type variables. This together with recent typing updates will fix #2878 I think.

miedzinski · 2017-02-28T16:20:32Z

@ilevkivskyi, done. PR updated so it will close #2878. I hope it's OK.

ilevkivskyi · 2017-03-01T08:46:47Z

It looks good to me.
But as I understand @JukkaL decided to make the release today, so that this PR (and many others) will go to the next cycle.

JukkaL · 2017-03-08T20:31:16Z

test-data/unit/check-incremental.test

+[out2]
+main:4: error: Cannot assign to class variable "x" via instance
+
+[case testIncrementalClassVarGone]


Can you add another incremental test that caches a class with a ClassVar (this module is not changed)? Another file then introduces in the .next file an assignment to the class variable via instance, which should be flagged.

JukkaL · 2017-03-08T20:33:20Z

I checked that this doesn't conflict with Dropbox code bases.

I only did a quick pass but this looks good. Thanks for writing such extensive tests! I had one idea for an additional test. Additionally, there a few simple merge conflicts. This should be almost ready to merge, unless @gvanrossum has some comments.

JukkaL · 2017-03-09T19:05:02Z

🎉

miedzinski added 2 commits February 15, 2017 23:46

Implement ClassVar semantics (fixes python#2771)

d6b370d

Fix type annotations

950b383

ilevkivskyi requested changes Feb 15, 2017

View reviewed changes

Remove ClassVarType, use Var.is_classvar flag

cdfdbbc

miedzinski force-pushed the classvar branch from 27ddabc to cdfdbbc Compare February 16, 2017 20:36

Add test case against TypeVar

01a7a69

ilevkivskyi requested changes Feb 17, 2017

View reviewed changes

miedzinski added 3 commits February 17, 2017 14:43

Fix if statement in check_classvar_definition

d52b4e3

Change error message about ClassVar arg count

15e1e85

Add more tests

781245f

ilevkivskyi reviewed Feb 17, 2017

View reviewed changes

Remove duplicate test case

cd61a5d

ilevkivskyi reviewed Feb 17, 2017

View reviewed changes

Move ClassVar override checks to TypeChecker

9c29911

miedzinski force-pushed the classvar branch from 1de9b6a to 9c29911 Compare February 17, 2017 17:58

Prohibit ClassVar inside other types or in signatures

b618718

miedzinski mentioned this pull request Feb 17, 2017

Generic class atributes aren't fully instantiated #2878

Closed

miedzinski added 2 commits February 17, 2017 22:18

Prohibit defining ClassVars on self

cb6786f

Add more tests

a427d61

ilevkivskyi requested changes Feb 18, 2017

View reviewed changes

miedzinski added 6 commits February 18, 2017 13:57

Fix analysing implicit tuple types

35e2c68

Add more meaningful error message on attribute override

e121158

Add better error message on assignments

5e2aafc

Add more precise errors on ClassVar definitions

137215e

Minor style improvements

5dd131a

Prohibit ClassVars in for and with statements

30a4185

Rename check_classvar_definition to is_classvar

bcce34d

ilevkivskyi reviewed Feb 19, 2017

View reviewed changes

Don't consider types in signatures as nested

7ddca4b

ilevkivskyi approved these changes Feb 19, 2017

View reviewed changes

Prohibit generic class variables

92b3532

Prohibit access to generic instance variables via class

20b1abe

JukkaL reviewed Mar 8, 2017

View reviewed changes

miedzinski added 2 commits March 9, 2017 18:39

Merge branch 'master' into classvar

3362e65

Add incremental checking test

5430b32

JukkaL merged commit fb0917d into python:master Mar 9, 2017

ilevkivskyi mentioned this pull request Apr 14, 2017

Type variables bound by a generic class make no sense in static or class methods. #3172

Open

		@@ -1189,6 +1189,29 @@ def deserialize(cls, data: JsonDict) -> 'TypeType':
		return TypeType(Type.deserialize(data['item']))


		class ClassVarType(Type):

Implement ClassVar semantics (fixes #2771) #2873

Implement ClassVar semantics (fixes #2771) #2873

Conversation

miedzinski commented Feb 15, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ilevkivskyi commented Feb 15, 2017

miedzinski commented Feb 15, 2017

ilevkivskyi commented Feb 16, 2017 • edited Loading

miedzinski commented Feb 16, 2017 via email • edited Loading

elazarg commented Feb 16, 2017

miedzinski commented Feb 16, 2017

miedzinski commented Feb 16, 2017

ilevkivskyi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

miedzinski commented Feb 17, 2017

Choose a reason for hiding this comment

ilevkivskyi commented Feb 17, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ilevkivskyi commented Feb 17, 2017

miedzinski commented Feb 17, 2017

miedzinski commented Feb 17, 2017

ilevkivskyi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

miedzinski commented Feb 18, 2017

Choose a reason for hiding this comment

ilevkivskyi commented Feb 19, 2017

miedzinski commented Feb 19, 2017

ilevkivskyi commented Feb 19, 2017

miedzinski commented Feb 22, 2017

ilevkivskyi commented Feb 24, 2017

miedzinski commented Feb 28, 2017

ilevkivskyi commented Mar 1, 2017

Choose a reason for hiding this comment

JukkaL commented Mar 8, 2017

JukkaL commented Mar 9, 2017

miedzinski commented Feb 15, 2017 •

edited

Loading

ilevkivskyi commented Feb 16, 2017 •

edited

Loading

miedzinski commented Feb 16, 2017 via email •

edited

Loading