From 764324d8cd78e6c8a130478cee15ff4fcd1f6514 Mon Sep 17 00:00:00 2001
From: Adrian Garcia Badaracco <1755071+adriangb@users.noreply.github.com>
Date: Sat, 5 Oct 2024 17:29:26 -0500
Subject: [PATCH] PEP 746: Rename __supports_type__ to
 __supports_annotated_base__ (#4019)

---
 peps/pep-0746.rst | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/peps/pep-0746.rst b/peps/pep-0746.rst
index f2e0f1f82..342b730aa 100644
--- a/peps/pep-0746.rst
+++ b/peps/pep-0746.rst
@@ -15,7 +15,7 @@ Abstract
 
 This PEP proposes a mechanism for type checking metadata that uses
 the :py:data:`typing.Annotated` type. Metadata objects that implement
-the new ``__supports_type__`` protocol will be type checked by static
+the new ``__supports_annotated_base__`` protocol will be type checked by static
 type checkers to ensure that the metadata is valid for the given type.
 
 Motivation
@@ -47,11 +47,11 @@ Specification
 =============
 This PEP introduces a protocol that can be used by static and runtime type checkers to validate
 the consistency between ``Annotated`` metadata and a given type.
-Objects that implement this protocol have an attribute called ``__supports_type__``
+Objects that implement this protocol have an attribute called ``__supports_annotated_base__``
 that specifies whether the metadata is valid for a given type::
 
     class Int64:
-        __supports_type__: int
+        __supports_annotated_base__: int
 
 The attribute may also be marked as a ``ClassVar`` to avoid interaction with dataclasses::
     
@@ -61,14 +61,14 @@ The attribute may also be marked as a ``ClassVar`` to avoid interaction with dat
     @dataclass
     class Gt:
         value: int
-        __supports_type__: ClassVar[int]
+        __supports_annotated_base__: ClassVar[int]
 
 When a static type checker encounters a type expression of the form ``Annotated[T, M1, M2, ...]``,
 it should enforce that for each metadata element in ``M1, M2, ...``, one of the following is true:
 
-* The metadata element evaluates to an object that does not have a ``__supports_type__`` attribute; or
-* The metadata element evaluates to an object ``M`` that has a ``__supports_type__`` attribute;
-  and ``T`` is assignable to the type of ``M.__supports_type__``.
+* The metadata element evaluates to an object that does not have a ``__supports_annotated_base__`` attribute; or
+* The metadata element evaluates to an object ``M`` that has a ``__supports_annotated_base__`` attribute;
+  and ``T`` is assignable to the type of ``M.__supports_annotated_base__``.
 
 To support generic ``Gt`` metadata, one might write::
 
@@ -79,7 +79,7 @@ To support generic ``Gt`` metadata, one might write::
             ...
     
     class Gt[T]:
-        __supports_type__: ClassVar[SupportsGt[T]]
+        __supports_annotated_base__: ClassVar[SupportsGt[T]]
 
         def __init__(self, value: T) -> None:
             self.value = value
@@ -137,8 +137,8 @@ does not generally use marker base classes. In addition, it provides less flexib
 the current proposal: it would not allow overloads, and it would require metadata objects
 to add a new base class, which may make their runtime implementation more complex.
 
-Using a method instead of an attribute for ``__supports_type__``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Using a method instead of an attribute for ``__supports_annotated_base__``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 We considered using a method instead of an attribute for the protocol, so that this method can be used
 at runtime to check the validity of the metadata and to support overloads or returning boolean literals.