PEP 746: Rename __supports_type__ to __supports_annotated_base__ (#4019)

This commit is contained in:
Adrian Garcia Badaracco 2024-10-05 17:29:26 -05:00 committed by GitHub
parent 7ccefe1e2f
commit 764324d8cd
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 10 additions and 10 deletions

View File

@ -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.