[mypyc] Use lower-case generic types such as "list[t]" in docs

mypyc/doc/differences_from_python.rst

@@ -107,7 +107,7 @@ performance.
 integer values. A side effect of this is that the exact runtime type of
 ``int`` values is lost. For example, consider this simple function::
 
-    def first_int(x: List[int]) -> int:
+    def first_int(x: list[int]) -> int:
         return x[0]
 
     print(first_int([True]))  # Output is 1, instead of True!

mypyc/doc/native_classes.rst

@@ -56,7 +56,7 @@ These non-native classes can be used as base classes of native
 classes:
 
 * ``object``
-* ``dict`` (and ``Dict[k, v]``)
+* ``dict`` (and ``dict[k, v]``)
 * ``BaseException``
 * ``Exception``
 * ``ValueError``

mypyc/doc/performance_tips_and_tricks.rst

@@ -57,12 +57,11 @@ here we call ``acme.get_items()``, but it has no type annotation. We
 can use an explicit type annotation for the variable to which we
 assign the result::
 
-    from typing import List, Tuple
     import acme
 
     def work() -> None:
         # Annotate "items" to help mypyc
-        items: List[Tuple[int, str]] = acme.get_items()
+        items: list[tuple[int, str]] = acme.get_items()
         for item in items:
             ...  # Do some work here
 
@@ -140,7 +139,7 @@ Similarly, caching a frequently called method in a local variable can
 help in CPython, but it can slow things down in compiled code, since
 the code won't use :ref:`early binding <early-binding>`::
 
-    def squares(n: int) -> List[int]:
+    def squares(n: int) -> list[int]:
         a = []
         append = a.append  # Not a good idea in compiled code!
         for i in range(n):

mypyc/doc/using_type_annotations.rst

@@ -37,10 +37,10 @@ implementations:
 * ``float`` (:ref:`native operations <float-ops>`)
 * ``bool`` (:ref:`native operations <bool-ops>`)
 * ``str`` (:ref:`native operations <str-ops>`)
-* ``List[T]`` (:ref:`native operations <list-ops>`)
-* ``Dict[K, V]`` (:ref:`native operations <dict-ops>`)
-* ``Set[T]`` (:ref:`native operations <set-ops>`)
-* ``Tuple[T, ...]`` (variable-length tuple; :ref:`native operations <tuple-ops>`)
+* ``list[T]`` (:ref:`native operations <list-ops>`)
+* ``dict[K, V]`` (:ref:`native operations <dict-ops>`)
+* ``set[T]`` (:ref:`native operations <set-ops>`)
+* ``tuple[T, ...]`` (variable-length tuple; :ref:`native operations <tuple-ops>`)
 * ``None``
 
 The link after each type lists all supported native, optimized
@@ -61,10 +61,10 @@ variable. For example, here we have a runtime type error on the final
 line of ``example`` (the ``Any`` type means an arbitrary, unchecked
 value)::
 
-    from typing import List, Any
+    from typing import Any
 
-    def example(a: List[Any]) -> None:
-        b: List[int] = a  # No error -- items are not checked
+    def example(a: list[Any]) -> None:
+        b: list[int] = a  # No error -- items are not checked
         print(b[0])  # Error here -- got str, but expected int
 
     example(["x"])
@@ -126,7 +126,7 @@ Tuple types
 
 Fixed-length
 `tuple types <https://mypy.readthedocs.io/en/stable/kinds_of_types.html#tuple-types>`_
-such as ``Tuple[int, str]`` are represented
+such as ``tuple[int, str]`` are represented
 as :ref:`value types <value-and-heap-types>` when stored in variables,
 passed as arguments, or returned from functions. Value types are
 allocated in the low-level machine stack or in CPU registers, as