Skip to content

Commit

Permalink
PEP 746: Rename __supports_type__ to __supports_annotated_base__ (pyt…
Browse files Browse the repository at this point in the history
  • Loading branch information
adriangb authored Oct 5, 2024
1 parent 7ccefe1 commit 764324d
Showing 1 changed file with 10 additions and 10 deletions.
20 changes: 10 additions & 10 deletions peps/pep-0746.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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::
Expand All @@ -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::

Expand All @@ -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
Expand Down Expand Up @@ -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.
Expand Down

0 comments on commit 764324d

Please sign in to comment.