Skip to content

Commit

Permalink
PEP 746: rename __supports_type__ to __supports_annotated_base__
Browse files Browse the repository at this point in the history
  • Loading branch information
adriangb committed Oct 5, 2024
1 parent 7ccefe1 commit 2fcca6a
Showing 1 changed file with 9 additions and 9 deletions.
18 changes: 9 additions & 9 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,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
Expand Down

0 comments on commit 2fcca6a

Please sign in to comment.