Update all links

Author: AA-Turner

peps/pep-0688.rst

@@ -349,7 +349,7 @@ How to Teach This
 =================
 
 We will add notes pointing to ``collections.abc.Buffer`` in appropriate places in the
-documentation, such as `typing.readthedocs.io <https://typing.readthedocs.io/en/latest/>`__
+documentation, such as `typing.python.org <https://typing.python.org/en/latest/>`__
 and the `mypy cheat sheet <https://mypy.readthedocs.io/en/stable/cheat_sheet_py3.html>`__.
 Type checkers may provide additional pointers in their error messages. For example,
 when they encounter a buffer object being passed to a function that

peps/pep-0692.rst

@@ -457,7 +457,7 @@ This PEP could be linked in the ``typing`` module's documentation. Moreover, a
 new section on using ``Unpack`` could be added to the aforementioned docs.
 Similar sections could be also added to the
 `mypy documentation <https://mypy.readthedocs.io/>`_ and the
-`typing RTD documentation <https://typing.readthedocs.io/>`_.
+`typing documentation <https://typing.python.org/>`_.
 
 Reference Implementation
 ========================

peps/pep-0728.rst

@@ -160,7 +160,7 @@ assignable to the ``extra_items`` argument.
 There are some advantages to this approach:
 
 - We can build on top of the `assignability rules defined in the typing spec
-  <https://typing.readthedocs.io/en/latest/spec/typeddict.html#assignability>`__,
+  <https://typing.python.org/en/latest/spec/typeddict.html#assignability>`__,
   where ``extra_items`` can be treated as a pseudo-item.
 
 - There is no need to introduce a grammar change to specify the type of the
@@ -182,7 +182,7 @@ If ``extra_items`` is specified, extra items are treated as :ref:`non-required
 <typing:required-notrequired>`
 items matching the ``extra_items`` argument, whose keys are allowed when
 determining `supported and unsupported operations
-<https://typing.readthedocs.io/en/latest/spec/typeddict.html#supported-and-unsupported-operations>`__.
+<https://typing.python.org/en/latest/spec/typeddict.html#supported-and-unsupported-operations>`__.
 
 The ``extra_items`` Class Parameter
 -----------------------------------
@@ -306,9 +306,9 @@ It is an error to use ``Required[]`` or ``NotRequired[]`` with ``extra_items``.
 ``total=False`` and ``total=True`` have no effect on ``extra_items`` itself.
 
 The extra items are non-required, regardless of the `totality
-<https://typing.readthedocs.io/en/latest/spec/typeddict.html#totality>`__ of the
+<https://typing.python.org/en/latest/spec/typeddict.html#totality>`__ of the
 TypedDict. `Operations
-<https://typing.readthedocs.io/en/latest/spec/typeddict.html#supported-and-unsupported-operations>`__
+<https://typing.python.org/en/latest/spec/typeddict.html#supported-and-unsupported-operations>`__
 that are available to ``NotRequired`` items should also be available to the
 extra items::
 
@@ -356,7 +356,7 @@ Inheritance
 
 ``extra_items`` is inherited in a similar way as a regular ``key: value_type``
 item. As with the other keys, the `inheritance rules
-<https://typing.readthedocs.io/en/latest/spec/typeddict.html#inheritance>`__
+<https://typing.python.org/en/latest/spec/typeddict.html#inheritance>`__
 and :ref:`Read-only Items <typing:readonly>` inheritance rules apply.
 
 We need to reinterpret these rules to define how ``extra_items`` interacts with
@@ -594,7 +594,7 @@ are assignable to ``VT``. For the purpose of this rule, a
 TypedDict that does not have ``extra_items=`` or ``closed=`` set is considered
 to have an item with a value of type ``object``. This extends the current
 assignability rule from the `typing spec
-<https://typing.readthedocs.io/en/latest/spec/typeddict.html#assignability>`__.
+<https://typing.python.org/en/latest/spec/typeddict.html#assignability>`__.
 
 For example::
 

peps/pep-0729.rst

@@ -367,7 +367,7 @@ documentation for normal usage.
 
 Therefore, a separate user-facing reference for the type system would be
 useful. Such an effort could expand the documentation on
-`typing.readthedocs.io <https://typing.readthedocs.io/en/latest/>`_ and
+`typing.python.org <https://typing.python.org/en/latest/>`_ and
 reuse material from the documentation sections of individual type checkers
 and the CPython documentation.
 

peps/pep-0767.rst

@@ -111,7 +111,7 @@ Those requirements are satisfiable at runtime by all of the following:
 * an object with a ``@property`` ``def name(self) -> T``,
 * an object with a custom descriptor, such as :func:`functools.cached_property`.
 
-The current `typing spec <https://typing.readthedocs.io/en/latest/spec/protocol.html#protocol-members>`_
+The current `typing spec <https://typing.python.org/en/latest/spec/protocol.html#protocol-members>`_
 allows creation of such protocol members using (abstract) properties::
 
     class HasName(Protocol):
@@ -554,11 +554,11 @@ following the footsteps of :pep:`705#how-to-teach-this`:
     a ``TypedDict`` as read-only.
 
 * Add a standalone entry for ``ReadOnly`` under the
-  `type qualifiers <https://typing.readthedocs.io/en/latest/spec/qualifiers.html>`_ section:
+  `type qualifiers <https://typing.python.org/en/latest/spec/qualifiers.html>`_ section:
 
     The ``ReadOnly`` type qualifier in class attribute annotations indicates
     that the attribute of the class may be read, but not reassigned or ``del``\ eted.
-    For usage in ``TypedDict``, see `ReadOnly <https://typing.readthedocs.io/en/latest/spec/typeddict.html#typing-readonly-type-qualifier>`_.
+    For usage in ``TypedDict``, see `ReadOnly <https://typing.python.org/en/latest/spec/typeddict.html#typing-readonly-type-qualifier>`_.
 
 
 Rejected Ideas
@@ -611,7 +611,7 @@ read-only attributes in such methods. It is unclear whether the rules could be
 satisfyingly shaped in a way that is inclusive of those 3rd party hooks, while
 upkeeping the invariants associated with the read-only-ness of those attributes.
 
-The Python type system has a long and detailed `specification <https://typing.readthedocs.io/en/latest/spec/constructors.html>`_
+The Python type system has a long and detailed `specification <https://typing.python.org/en/latest/spec/constructors.html>`_
 regarding the behavior of ``__new__`` and ``__init__``. It is rather unfeasible
 to expect the same level of detail from 3rd party hooks.
 
@@ -641,7 +641,7 @@ Footnotes
     `[Pyre] <https://pyre-check.org/play/?input=%23%20pyre-strict%0Afrom%20abc%20import%20abstractmethod%0Afrom%20functools%20import%20cached_property%0Afrom%20typing%20import%20ClassVar%2C%20Protocol%2C%20final%0A%0A%0Aclass%20HasFoo(Protocol)%3A%0A%20%20%20%20%40property%0A%20%20%20%20%40abstractmethod%0A%20%20%20%20def%20foo(self)%20-%3E%20int%3A%20...%0A%0A%0A%23%20assignability%0A%0A%0Aclass%20FooAttribute%3A%0A%20%20%20%20foo%3A%20int%0A%0Aclass%20FooProperty%3A%0A%20%20%20%20%40property%0A%20%20%20%20def%20foo(self)%20-%3E%20int%3A%20return%200%0A%0Aclass%20FooClassVar%3A%0A%20%20%20%20foo%3A%20ClassVar%5Bint%5D%20%3D%200%0A%0Aclass%20FooDescriptor%3A%0A%20%20%20%20%40cached_property%0A%20%20%20%20def%20foo(self)%20-%3E%20int%3A%20return%200%0A%0Aclass%20FooPropertyCovariant%3A%0A%20%20%20%20%40property%0A%20%20%20%20def%20foo(self)%20-%3E%20bool%3A%20return%20False%0A%0Aclass%20FooInvalid%3A%0A%20%20%20%20foo%3A%20str%0A%0Aclass%20NoFoo%3A%0A%20%20%20%20bar%3A%20str%0A%0A%0Aobj%3A%20HasFoo%0Aobj%20%3D%20FooAttribute()%20%20%23%20ok%0Aobj%20%3D%20FooProperty()%20%20%20%23%20ok%0Aobj%20%3D%20FooClassVar%20%20%20%20%20%23%20ok%0Aobj%20%3D%20FooClassVar()%20%20%20%23%20ok%0Aobj%20%3D%20FooDescriptor()%20%23%20ok%0Aobj%20%3D%20FooPropertyCovariant()%20%23%20ok%0Aobj%20%3D%20FooInvalid()%20%20%20%20%23%20err%0Aobj%20%3D%20NoFoo()%20%20%20%20%20%20%20%20%20%23%20err%0Aobj%20%3D%20None%20%20%20%20%20%20%20%20%20%20%20%20%23%20err%0A%0A%0A%23%20explicit%20impl%0A%0A%0Aclass%20FooAttributeImpl(HasFoo)%3A%0A%20%20%20%20foo%3A%20int%0A%0Aclass%20FooPropertyImpl(HasFoo)%3A%0A%20%20%20%20%40property%0A%20%20%20%20def%20foo(self)%20-%3E%20int%3A%20return%200%0A%0Aclass%20FooClassVarImpl(HasFoo)%3A%0A%20%20%20%20foo%3A%20ClassVar%5Bint%5D%20%3D%200%0A%0Aclass%20FooDescriptorImpl(HasFoo)%3A%0A%20%20%20%20%40cached_property%0A%20%20%20%20def%20foo(self)%20-%3E%20int%3A%20return%200%0A%0Aclass%20FooPropertyCovariantImpl(HasFoo)%3A%0A%20%20%20%20%40property%0A%20%20%20%20def%20foo(self)%20-%3E%20bool%3A%20return%20False%0A%0Aclass%20FooInvalidImpl(HasFoo)%3A%0A%20%20%20%20foo%3A%20str%0A%0A%40final%0Aclass%20NoFooImpl(HasFoo)%3A%0A%20%20%20%20bar%3A%20str%0A>`_
 
 .. [#final_mutability]
-    As noted above the second-to-last code example of https://typing.readthedocs.io/en/latest/spec/qualifiers.html#semantics-and-examples
+    As noted above the second-to-last code example of https://typing.python.org/en/latest/spec/qualifiers.html#semantics-and-examples
 
 
 Copyright