PEP 746: Rename __supports_type__ to __supports_annotated_base__ (#4019)
This commit is contained in:
parent
7ccefe1e2f
commit
764324d8cd
|
@ -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.
|
||||
|
|
Loading…
Reference in New Issue