Also #3208 (comment) is similar hole, might be worth opening separate issue for it

@hauntsaninja

We should accept:

Why should we allow this? x = 5 at class scope creates a new Var symbol (you can check that y: Y; reveal_type(y.x) will show an int), so it causes exactly the same unsafety (and also changing inference logic depending on an error code is a bad idea). The rules for whether we create a new Var or assign to the superclass' Var are these:

• If there is an annotation, always create a new Var (for both x: int and self.x: int)
• If there is no annotation, self.x = ... re-uses existing Var, but x = ... creates a new Var

You may be tempted to change these rules, but believe me they are very old, and may break some unexpected things (especially in the daemon). Or did you mean we should allow self.x = 5? This should be already allowed (for exactly the rules I listed above, since there is just one Var, there is nothing to compare with in superclass). Btw, this is a very good thing to test.

Also #3208 (comment) is similar hole, might be worth opening separate issue for it

Yes, this is a separate story, and there are problems not just for variables, but for methods as well.

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅