Introduce Y052: Disallow assignments to constant values in global or class namespaces where the assignments don't have type annotations

[AlexWaygood]

Following #326, we now allow constructs such as these in a stub file:

x = 1
y = "foo"
z = b"bar"

It's good that we now allow variables to have default values. However, the above constructs are problematic in a stub, as we're leaving it up to the type checker to make inferences about the types of these variables, which can have unpredictable consequences. For example, the x variable could be inferred to be of type int, Final[int], Literal[1], or Final[Literal[1]]. In a class namespace, the problem is even worse -- the eggs variable in the following snippet could reasonably be inferred as being of type str, ClassVar[str], Final[str], Literal["EGGS"], ClassVar[Literal["EGGS"]], or Final[Literal["EGGS"]]:

class Whatever:
    eggs = "EGGS"

This PR introduces Y052, enforcing type annotations for assignments to simple constants.

[AlexWaygood]

The only change in this line is a small grammar fix: "detect" -> "detects"

[AlexWaygood]

The tensorflow hit is two enums here: https://github.com/python/typeshed/blob/307aadc632bd7e80f427ad22ff036ebc53a5df2c/stubs/tensorflow/tensorflow/__init__.pyi#L79-L89

Strictly speaking, these are false positives, since the type of enum members needs to be special-cased by type checkers anyway, and the semantics of enums are well established. However, I also don't think it would do a huge amount of harm to add explicit type annotations:

 class VariableSynchronization(Enum):
-    AUTO = 0
-    NONE = 1
-    ON_WRITE = 2
-    ON_READ = 3
+    AUTO: int = 0
+    NONE: int = 1
+    ON_WRITE: int = 2
+    ON_READ: int = 3

 class VariableAggregation(Enum):
-    AUTO = 0
-    NONE = 1
-    ON_WRITE = 2
-    ON_READ = 3
+    AUTO: int = 0
+    NONE: int = 1
+    ON_WRITE: int = 2
+    ON_READ: int = 3

The netaddr hit is here: https://github.com/python/typeshed/blob/307aadc632bd7e80f427ad22ff036ebc53a5df2c/stubs/netaddr/netaddr/strategy/ipv6.pyi#L11

It does this:

from netaddr.fbsocket import AF_INET6

family: Final = AF_INET6

AF_INET6 is defined as Literal[2] in netaddr.fbsocket. It would arguably be more explicit to annotate the family variable above as Literal[2] as well, so this is arguably a true positive.

[AlexWaygood]

I changed my mind about how acceptable the netaddr hit was; added some special-casing for Final to fix it.

[JelleZijlstra]

This looks good but the enum change you suggest would cause a regression: https://mypy-play.net/?mypy=latest&python=3.10&gist=b2ec11ec1691fec01fd1054d51335357

With enum members defined as x = 3, mypy infers that .x.value is Literal[3]; with x: int = 3 it doesn't.

[JelleZijlstra]

Though x: Literal[3] = 3 does work.

[github-actions]

This change has no effect on typeshed. 🤖🎉

[AlexWaygood]

Okay, I added some hacky special-casing for enums so that they're excluded from the new check :(

[JelleZijlstra]

Thanks! At some point we may have to do some consensus-gathering to get aligned on how to annotate enums in stubs.