Respond to code review

python · Michael0x2a · Nov 15, 2019 · Nov 14, 2019 · Nov 15, 2019 · Nov 15, 2019
commit b4606dc2f295b867beaf81c7182a655cc396a779
diff --git a/docs/source/literal_types.rst b/docs/source/literal_types.rst
@@ -125,9 +125,12 @@ you can instead change the variable to be ``Final`` (see :ref:`final_attrs`):
     expects_literal(c)      # ...and this type checks!
 
 If you do not provide an explicit type in the ``Final``, the type of ``c`` becomes
-context-sensitive: mypy will basically try "substituting" the original assigned
-value whenever it's used before performing type checking. So, mypy will type-check
-the above program almost as if it were written like so:
+*context-sensitive*: mypy will basically try "substituting" the original assigned
+value whenever it's used before performing type checking. This is why the revealed
+type of ``c`` is ``Literal[19]?``: the question mark at the end reflects this
+context-sensitive nature.
+
+For example, mypy will type check the above program almost as if it were written like so:
 
 .. code-block:: python
 
@@ -138,9 +141,13 @@ the above program almost as if it were written like so:
     reveal_type(19)
     expects_literal(19)
 
-In other words, the type of ``c`` is *context-dependent*: It could be either ``int``
-or ``Literal[19]`` depending on where it's used. For example, here is an example of
-where mypy will decide to use ``int`` over ``Literal[19]``:
+This means that while changing a variable to be ``Final`` is not quite the same thing
+as adding an explicit ``Literal[...]`` annotation, it often leads to the same effect
+in practice.
+
+The main cases where the behavior of context-sensitive vs true literal types differ are
+when you try using those types in places that are not explicitly expecting a ``Literal[...]``. 
+For example, compare and contrast what happens when you try appending these types to a list:
 
 ..code-block:: python
-..code-block:: python
+.. code-block:: python
-..code-block:: python
+.. code-block:: python
 
@@ -149,19 +156,18 @@ where mypy will decide to use ``int`` over ``Literal[19]``:
     a: Final = 19
     b: Literal[19] = 19
 
+    # Mypy will chose to infer List[int] instead of List[Literal[19]?] or
+    # List[Literal[19]] since the former is most likely more useful.
     list_of_ints = []
     list_of_ints.append(a)
     reveal_type(list_of_ints)  # Revealed type is 'List[int]'
 
+    # But if the variable you're appending is an explicit Literal, mypy
+    # will infer List[Literal[19]].
     list_of_lits = []
     list_of_lits.append(b)
     reveal_type(list_of_lits)  # Revealed type is 'List[Literal[19]]'
 
-This is why the revealed type of ``c`` is ``Literal[19]?``: the question mark at
-the end indicates the context-sensitive nature of ``c``.
-
-So while changing a variable to be ``Final`` is not quite the same thing as adding
-an explicit ``Literal[...]`` annotation, it often leads to the same effect in practice.
 
 Limitations
 ***********

diff --git a/mypy/checkmember.py b/mypy/checkmember.py
@@ -693,7 +693,7 @@ def analyze_class_attribute_access(itype: Instance,
         enum_literal = LiteralType(name, fallback=itype)
         # When we analyze enums, the corresponding Instance is always considered to be erased
         # due to how the signature of Enum.__new__ is `(cls: Type[_T], value: object) -> _T`
-        # in Typeshed. However, this is really more of an implementation detail of how Enums
+        # in typeshed. However, this is really more of an implementation detail of how Enums
         # are typed, and we really don't want to treat every single Enum value as if it were
         # from type variable substitution. So we reset the 'erased' field here.
         return itype.copy_modified(erased=False, last_known_value=enum_literal)

diff --git a/test-data/unit/check-literal.test b/test-data/unit/check-literal.test
@@ -2564,7 +2564,7 @@ force4(reveal_type(f.instancevar4))  # N: Revealed type is 'None'
 [builtins fixtures/primitives.pyi]
 [out]
 
-[case testLiteralFinalErasureInMutableDatastructures]
+[case testLiteralFinalErasureInMutableDatastructures1]
 # flags: --strict-optional
 from typing_extensions import Final
 
@@ -2575,6 +2575,24 @@ reveal_type(var1)  # N: Revealed type is 'builtins.list[Union[builtins.int, None
 reveal_type(var2)  # N: Revealed type is 'Tuple[Literal[0]?, None]'
 [builtins fixtures/tuple.pyi]
 
+[case testLiteralFinalErasureInMutableDatastructures2]
+from typing_extensions import Final, Literal
+
+var1: Final = []
+var1.append(0)
+reveal_type(var1)  # N: Revealed type is 'builtins.list[builtins.int]'
+
+var2 = []
+var2.append(0)
+reveal_type(var2)  # N: Revealed type is 'builtins.list[builtins.int]'
+
+x: Literal[0] = 0
+var3 = []
+var3.append(x)
+reveal_type(var3)  # N: Revealed type is 'builtins.list[Literal[0]]'
+
+[builtins fixtures/list.pyi]
+
 [case testLiteralFinalMismatchCausesError]
 from typing_extensions import Final, Literal
 

diff --git a/test-data/unit/check-python38.test b/test-data/unit/check-python38.test
@@ -226,7 +226,7 @@ def f(x: int = (c := 4)) -> int:
     f(x=(y7 := 3))
     reveal_type(y7)  # N: Revealed type is 'builtins.int'
 
-    reveal_type((lambda: (y8 := 3) and y8)())  # N: Revealed type is 'builtins.int'
+    reveal_type((lambda: (y8 := 3) and y8)())  # N: Revealed type is 'Literal[3]?'
     y8  # E: Name 'y8' is not defined
 
     y7 = 1.0  # E: Incompatible types in assignment (expression has type "float", variable has type "int")
@@ -240,7 +240,11 @@ def f(x: int = (c := 4)) -> int:
     if Alias := int:
         z3: Alias  # E: Variable "Alias" is not valid as a type
 
-    return (y9 := 3) + y9
+    if reveal_type(y9 := 3) and \  # N: Revealed type is 'Literal[3]?'
+            reveal_type(y9):       # N: Revealed type is 'builtins.int'
+        reveal_type(y9)            # N: Revealed type is 'builtins.int'
+
+    return (y10 := 3) + y10
 
 reveal_type(c)  # N: Revealed type is 'builtins.int'