Skip to content

Commit 764324d

Browse files
authored
PEP 746: Rename __supports_type__ to __supports_annotated_base__ (#4019)
1 parent 7ccefe1 commit 764324d

File tree

1 file changed

+10
-10
lines changed

1 file changed

+10
-10
lines changed

peps/pep-0746.rst

Lines changed: 10 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -15,7 +15,7 @@ Abstract
1515

1616
This PEP proposes a mechanism for type checking metadata that uses
1717
the :py:data:`typing.Annotated` type. Metadata objects that implement
18-
the new ``__supports_type__`` protocol will be type checked by static
18+
the new ``__supports_annotated_base__`` protocol will be type checked by static
1919
type checkers to ensure that the metadata is valid for the given type.
2020

2121
Motivation
@@ -47,11 +47,11 @@ Specification
4747
=============
4848
This PEP introduces a protocol that can be used by static and runtime type checkers to validate
4949
the consistency between ``Annotated`` metadata and a given type.
50-
Objects that implement this protocol have an attribute called ``__supports_type__``
50+
Objects that implement this protocol have an attribute called ``__supports_annotated_base__``
5151
that specifies whether the metadata is valid for a given type::
5252

5353
class Int64:
54-
__supports_type__: int
54+
__supports_annotated_base__: int
5555

5656
The attribute may also be marked as a ``ClassVar`` to avoid interaction with dataclasses::
5757
@@ -61,14 +61,14 @@ The attribute may also be marked as a ``ClassVar`` to avoid interaction with dat
6161
@dataclass
6262
class Gt:
6363
value: int
64-
__supports_type__: ClassVar[int]
64+
__supports_annotated_base__: ClassVar[int]
6565

6666
When a static type checker encounters a type expression of the form ``Annotated[T, M1, M2, ...]``,
6767
it should enforce that for each metadata element in ``M1, M2, ...``, one of the following is true:
6868

69-
* The metadata element evaluates to an object that does not have a ``__supports_type__`` attribute; or
70-
* The metadata element evaluates to an object ``M`` that has a ``__supports_type__`` attribute;
71-
and ``T`` is assignable to the type of ``M.__supports_type__``.
69+
* The metadata element evaluates to an object that does not have a ``__supports_annotated_base__`` attribute; or
70+
* The metadata element evaluates to an object ``M`` that has a ``__supports_annotated_base__`` attribute;
71+
and ``T`` is assignable to the type of ``M.__supports_annotated_base__``.
7272

7373
To support generic ``Gt`` metadata, one might write::
7474

@@ -79,7 +79,7 @@ To support generic ``Gt`` metadata, one might write::
7979
...
8080
8181
class Gt[T]:
82-
__supports_type__: ClassVar[SupportsGt[T]]
82+
__supports_annotated_base__: ClassVar[SupportsGt[T]]
8383

8484
def __init__(self, value: T) -> None:
8585
self.value = value
@@ -137,8 +137,8 @@ does not generally use marker base classes. In addition, it provides less flexib
137137
the current proposal: it would not allow overloads, and it would require metadata objects
138138
to add a new base class, which may make their runtime implementation more complex.
139139

140-
Using a method instead of an attribute for ``__supports_type__``
141-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
140+
Using a method instead of an attribute for ``__supports_annotated_base__``
141+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
142142

143143
We considered using a method instead of an attribute for the protocol, so that this method can be used
144144
at runtime to check the validity of the metadata and to support overloads or returning boolean literals.

0 commit comments

Comments
 (0)