From 2fcca6a07bf5894998e279f43113035804dc580c Mon Sep 17 00:00:00 2001
From: Adrian Garcia Badaracco <1755071+adriangb@users.noreply.github.com>
Date: Sat, 5 Oct 2024 13:14:21 -0500
Subject: [PATCH] PEP 746: rename __supports_type__ to
 __supports_annotated_base__

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

diff --git a/peps/pep-0746.rst b/peps/pep-0746.rst
index f2e0f1f8229..6b068046193 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,7 +137,7 @@ 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