# `typing` — Soporte para type hints

Nuevo en la versión 3.5.

Source code: Lib/typing.py

Nota

En tiempo de ejecución, Python no impone las anotaciones de tipado en funciones y variables. Pueden ser utilizadas por herramientas de terceros como validadores de tipado, IDEs, linters, etc.

This module provides runtime support for type hints. The most fundamental support consists of the types `Any`, `Union`, `Callable`, `TypeVar`, and `Generic`. For a full specification, please see PEP 484. For a simplified introduction to type hints, see PEP 483.

La siguiente función toma y retorna una cadena de texto, que se anota de la siguiente manera:

    def greeting(name: str) -> str:
        return 'Hello ' + name

En la función `greeting`, se espera que el argumento `name` sea de tipo `str` y que el tipo retornado sea `str`. Los subtipos también son aceptados como argumento válido.

New features are frequently added to the `typing` module. The typing_extensions package provides backports of these new features to older versions of Python.

## Relevant PEPs

Since the initial introduction of type hints in PEP 484 and PEP 483, a number of PEPs have modified and enhanced Python’s framework for type annotations. These include:

- PEP 526: Syntax for Variable Annotations

    Introducing syntax for annotating variables outside of function definitions, and `ClassVar`

- PEP 544: Protocols: Structural subtyping (static duck typing)

    Introducing `Protocol` and the `@runtime_checkable` decorator

- PEP 585: Type Hinting Generics In Standard Collections

    Introducing `types.GenericAlias` and the ability to use standard library classes as generic types

- PEP 586: Literal Types

    Introducing `Literal`

- PEP 589: TypedDict: Type Hints for Dictionaries with a Fixed Set of Keys

    Introducing `TypedDict`

- PEP 591: Adding a final qualifier to typing

    Introducing `Final` and the `@final` decorator

- PEP 593: Flexible function and variable annotations

    Introducing `Annotated`

## Alias de tipo

Un alias de tipo se define asignando el tipo al alias. En este ejemplo, `Vector` y `List[float]` serán tratados como sinónimos intercambiables:

    Vector = list[float]

    def scale(scalar: float, vector: Vector) -> Vector:
        return [scalar * num for num in vector]

    # typechecks; a list of floats qualifies as a Vector.
    new_vector = scale(2.0, [1.0, -4.2, 5.4])

Los alias de tipo son útiles para simplificar indicadores de tipo complejos. Por ejemplo:

    from collections.abc import Sequence

    ConnectionOptions = dict[str, str]
    Address = tuple[str, int]
    Server = tuple[Address, ConnectionOptions]

    def broadcast_message(message: str, servers: Sequence[Server]) -> None:
        ...

    # The static type checker will treat the previous type signature as
    # being exactly equivalent to this one.
    def broadcast_message(
            message: str,
            servers: Sequence[tuple[tuple[str, int], dict[str, str]]]) -> None:
        ...

Nótese que `None` como indicador de tipo es un caso especial y es substituido por `type(None)`.

## NewType

Use the `NewType()` helper to create distinct types:

    from typing import NewType

    UserId = NewType('UserId', int)
    some_id = UserId(524313)

El validador estático de tipos tratará el nuevo tipo como si fuera una subclase del tipo original. Esto es útil para capturar errores lógicos:

    def get_user_name(user_id: UserId) -> str:
        ...

    # typechecks
    user_a = get_user_name(UserId(42351))

    # does not typecheck; an int is not a UserId
    user_b = get_user_name(-1)

Se pueden realizar todas las operaciones de `int` en una variable de tipo `UserId`, pero el resultado siempre será de tipo `int`. Esto permite pasar un `UserId` allí donde se espere un `int`, pero evitará la creación accidental de un `UserId` de manera incorrecta:

    # 'output' is of type 'int', not 'UserId'
    output = UserId(23413) + UserId(54341)

Note that these checks are enforced only by the static type checker. At runtime, the statement `Derived = NewType('Derived', Base)` will make `Derived` a callable that immediately returns whatever parameter you pass it. That means the expression `Derived(some_value)` does not create a new class or introduce any overhead beyond that of a regular function call.

Más concretamente, la expresión `some_value is Derived(some_value)` será siempre verdadera en tiempo de ejecución.

Esto también implica que no es posible crear un subtipo de `Derived` ya que, en tiempo de ejecución, es una función de identidad, no un tipo propiamente dicho:

    from typing import NewType

    UserId = NewType('UserId', int)

    # Fails at runtime and does not typecheck
    class AdminUserId(UserId): pass

Sin embargo, es posible crear un `NewType()` basado en un `NewType` “derivado”:

    from typing import NewType

    UserId = NewType('UserId', int)

    ProUserId = NewType('ProUserId', UserId)

y la comprobación de tipo para `ProUserId` funcionará como se espera.

Véase PEP 484 para más detalle.

Nota

Recuérdese que el uso de alias de tipo implica que los dos tipos son equivalentes entre sí. Haciendo `Alias = Original` provocará que el Validador estático de tipos trate `Alias` como algo exactamente equivalente a `Original` en todos los casos. Esto es útil para cuando se quiera simplificar indicadores de tipo complejos.

En cambio, `NewType` declara un tipo que es subtipo de otro. Haciendo `Derived = NewType('Derived', Original)` hará que el Validador estático de tipos trate `Derived` como una subclase de `Original`, lo que implica que un valor de tipo `Original` no puede ser usado allí donde se espere un valor de tipo `Derived`. Esto es útil para prevenir errores lógicos con un coste de ejecución mínimo.

Nuevo en la versión 3.5.2.

## Callable

Entidades que esperen llamadas a funciones con interfaces específicas puede ser anotadas usando `Callable[[Arg1Type, Arg2Type], ReturnType]`.

Por ejemplo:

    from collections.abc import Callable

    def feeder(get_next_item: Callable[[], str]) -> None:
        # Body

    def async_query(on_success: Callable[[int], None],
                    on_error: Callable[[int, Exception], None]) -> None:
        # Body

    async def on_update(value: str) -> None:
        # Body
    callback: Callable[[str], Awaitable[None]] = on_update

Es posible declarar el tipo de retorno de un callable (invocable) sin especificar tipos en los parámetros substituyendo la lista de argumentos por unos puntos suspensivos (…) en el indicador de tipo: `Callable[..., ReturnType]`.

## Genéricos

Ya que no es posible inferir estáticamente y de una manera genérica la información de tipo de objetos dentro de contenedores, las clases base abstractas han sido mejoradas para permitir sintaxis de subíndice para denotar los tipos esperados en elementos contenedores.

    from collections.abc import Mapping, Sequence

    def notify_by_email(employees: Sequence[Employee],
                        overrides: Mapping[str, str]) -> None: ...

Generics can be parameterized by using a factory available in typing called `TypeVar`.

    from collections.abc import Sequence
    from typing import TypeVar

    T = TypeVar('T')      # Declare type variable

    def first(l: Sequence[T]) -> T:   # Generic function
        return l[0]

## Tipos genéricos definidos por el usuario

Una clase definida por el usuario puede ser definida como una clase genérica.

    from typing import TypeVar, Generic
    from logging import Logger

    T = TypeVar('T')

    class LoggedVar(Generic[T]):
        def __init__(self, value: T, name: str, logger: Logger) -> None:
            self.name = name
            self.logger = logger
            self.value = value

        def set(self, new: T) -> None:
            self.log('Set ' + repr(self.value))
            self.value = new

        def get(self) -> T:
            self.log('Get ' + repr(self.value))
            return self.value

        def log(self, message: str) -> None:
            self.logger.info('%s: %s', self.name, message)

`Generic[T]` como clase base define que la clase `LoggedVar` toma un solo parámetro `T`. Esto también implica que `T` es un tipo válido dentro del cuerpo de la clase.

The `Generic` base class defines `__class_getitem__()` so that `LoggedVar[t]` is valid as a type:

    from collections.abc import Iterable

    def zero_all_vars(vars: Iterable[LoggedVar[int]]) -> None:
        for var in vars:
            var.set(0)

A generic type can have any number of type variables. All varieties of `TypeVar` are permissible as parameters for a generic type:

    from typing import TypeVar, Generic, Sequence

    T = TypeVar('T', contravariant=True)
    B = TypeVar('B', bound=Sequence[bytes], covariant=True)
    S = TypeVar('S', int, str)

    class WeirdTrio(Generic[T, B, S]):
        ...

Cada argumento de variable de tipo en una clase `Generic` debe ser distinto. Así, no será válido:

    from typing import TypeVar, Generic
    ...

    T = TypeVar('T')

    class Pair(Generic[T, T]):   # INVALID
        ...

Se puede utilizar herencia múltiple con `Generic`:

    from collections.abc import Sized
    from typing import TypeVar, Generic

    T = TypeVar('T')

    class LinkedList(Sized, Generic[T]):
        ...

Cuando se hereda de clases genéricas, se pueden fijar algunas variables de tipo:

    from collections.abc import Mapping
    from typing import TypeVar

    T = TypeVar('T')

    class MyDict(Mapping[str, T]):
        ...

En este caso `MyDict` tiene un solo parámetro, `T`.

Al usar una clase genérica sin especificar parámetros de tipo se asume `Any` para todas las posiciones. En el siguiente ejemplo, `MyIterable` no es genérico pero hereda implícitamente de `Iterable[Any]`:

    from collections.abc import Iterable

    class MyIterable(Iterable): # Same as Iterable[Any]

Son posibles los alias de tipos genéricos definidos por el usuario. Ejemplos:

    from collections.abc import Iterable
    from typing import TypeVar, Union
    S = TypeVar('S')
    Response = Union[Iterable[S], int]

    # Return type here is same as Union[Iterable[str], int]
    def response(query: str) -> Response[str]:
        ...

    T = TypeVar('T', int, float, complex)
    Vec = Iterable[tuple[T, T]]

    def inproduct(v: Vec[T]) -> T: # Same as Iterable[tuple[T, T]]
        return sum(x*y for x, y in v)

Distinto en la versión 3.7: `Generic` ya no posee una metaclase personalizable.

Un clase genérica definida por el usuario puede tener clases ABC como clase base sin conflicto de metaclase. Las metaclases genéricas no están permitidas. El resultado de parametrizar clases genéricas se cachea, y la mayoría de los tipos en el módulo typing pueden tener un hash y ser comparables por igualdad (equality).

## El tipo `Any`

Un caso especial de tipo es `Any`. Un Validador estático de tipos tratará cualquier tipo como compatible con `Any`, y `Any` como compatible con todos los tipos.

Esto significa que es posible realizar cualquier operación o llamada a un método en un valor de tipo `Any` y asignarlo a cualquier variable:

    from typing import Any

    a: Any = None
    a = []          # OK
    a = 2           # OK

    s: str = ''
    s = a           # OK

    def foo(item: Any) -> int:
        # Typechecks; 'item' could be any type,
        # and that type might have a 'bar' method
        item.bar()
        ...

Nótese que no se realiza comprobación de tipo cuando se asigna un valor de tipo `Any` a un tipo más preciso. Por ejemplo, el Validador estático de tipos no reportó ningún error cuando se asignó `a` a `s`, aún cuando se declaró `s` como de tipo `str` y recibió un valor `int` en tiempo de ejecución!

Además, todas las funciones sin un tipo de retorno o tipos en los parámetros serán asignadas implícitamente a `Any` por defecto:

    def legacy_parser(text):
        ...
        return data

    # A static type checker will treat the above
    # as having the same signature as:
    def legacy_parser(text: Any) -> Any:
        ...
        return data

Este comportamiento permite que `Any` sea usado como una vía de escape cuando es necesario mezclar código tipado estática y dinámicamente.

Compárese el comportamiento de `Any` con el de `object`. De manera similar a `Any`, todo tipo es un subtipo de `object`. Sin embargo, en oposición a `Any`, lo contrario no es cierto: `object` no es un subtipo de ningún otro tipo.

Esto implica que cuando el tipo de un valor es `object`, un validador de tipos rechazará prácticamente todas las operaciones con él, y al asignarlo a una variable (o usarlo como valor de retorno) de un tipo más preciso será un error de tipo. Por ejemplo:

    def hash_a(item: object) -> int:
        # Fails; an object does not have a 'magic' method.
        item.magic()
        ...

    def hash_b(item: Any) -> int:
        # Typechecks
        item.magic()
        ...

    # Typechecks, since ints and strs are subclasses of object
    hash_a(42)
    hash_a("foo")

    # Typechecks, since Any is compatible with all types
    hash_b(42)
    hash_b("foo")

Úsese `object` para indicar que un valor puede ser de cualquier tipo de manera segura. Úsese `Any` para indicar que un valor es de tipado dinámico.

## Subtipado nominal vs estructural

Initially PEP 484 defined the Python static type system as using nominal subtyping. This means that a class `A` is allowed where a class `B` is expected if and only if `A` is a subclass of `B`.

Este requisito también se aplicaba anteriormente a clases base abstractas (ABC), tales como `Iterable`. El problema con esta estrategia es que una clase debía de ser marcada explícitamente para proporcionar tal funcionalidad, lo que resulta poco pythónico (idiomático) y poco ajustado a lo que uno normalmente haría en un código Python tipado dinámicamente. Por ejemplo, esto sí se ajusta al PEP 484:

    from collections.abc import Sized, Iterable, Iterator

    class Bucket(Sized, Iterable[int]):
        ...
        def __len__(self) -> int: ...
        def __iter__(self) -> Iterator[int]: ...

El PEP 544 permite resolver este problema al permitir escribir el código anterior sin una clase base explícita en la definición de la clase, permitiendo que el Validador estático de tipo considere implícitamente que `Bucket` es un subtipo tanto de `Sized` como de `Iterable[int]`. Esto se conoce como tipado estructural (o duck-typing estático):

    from collections.abc import Iterator, Iterable

    class Bucket:  # Note: no base classes
        ...
        def __len__(self) -> int: ...
        def __iter__(self) -> Iterator[int]: ...

    def collect(items: Iterable[int]) -> int: ...
    result = collect(Bucket())  # Passes type check

Asimismo, creando subclases de la clase especial `Protocol`, el usuario puede definir nuevos protocolos personalizados y beneficiarse del tipado estructural (véanse los ejemplos de abajo).

## Contenido del módulo

El módulo define las siguientes clases, funciones y decoradores.

Nota

Este módulo define algunos tipos que son subclases de clases que ya existen en la librería estándar, y que además extienden `Generic` para soportar variables de tipo dentro de `[]`. Estos tipos se vuelven redundantes en Python 3.9 ya que las clases correspondientes fueron mejoradas para soportar `[]`.

Los tipos redundantes están descontinuados con Python 3.9 pero el intérprete no mostrará ninguna advertencia. Se espera que los verificadores de tipo marquen estos tipos como obsoletos cuando el programa a verificar apunte a Python 3.9 o superior.

Los tipos obsoletos serán removidos del módulo `Generic` en la primera versión de Python que sea lanzada 5 años después del lanzamiento de Python 3.9.0. Véase los detalles en PEP 585 – Sugerencias de tipo genéricas en las Colecciones Estándar.

### Primitivos especiales de tipado

#### Tipos especiales

Estos pueden ser usados como tipos en anotaciones y no soportan `[]`.

`typing.``Any`

  Tipo especial que indica un tipo sin restricciones.

  - Todos los tipos son compatibles con `Any`.

  - `Any` es compatible con todos los tipos.

`typing.``NoReturn`

  Tipo especial que indica que una función nunca retorna un valor. Por ejemplo:

      from typing import NoReturn

      def stop() -> NoReturn:
          raise RuntimeError('no way')

  Nuevo en la versión 3.5.4.

  Nuevo en la versión 3.6.2.

#### Formas especiales

Estas se pueden usar como anotaciones de tipo usando `[]`, cada cual tiene una sintaxis única.

`typing.``Tuple`

  El tipo Tuple, `Tuple[X, Y]` es el tipo de una tupla de dos ítems con el primer ítem de tipo X y el segundo de tipo Y. El tipo de una tupla vacía se puede escribir así: `Tuple[()]`.

  Ejemplo: `Tuple[T1, T2]` es una tupla de dos elementos con sus correspondientes variables de tipo T1 y T2. `Tuple[int, float, str]` es un tupla con un número entero, un número de punto flotante y una cadena de texto.

  Para especificar una tupla de longitud variable y tipo homogéneo, se usan puntos suspensivos, p. ej. `Tuple[int, ...]`. Un simple `Tuple` es equivalente a `Tuple[Any, ...]` y, a su vez, a `tuple`.

  Obsoleto desde la versión 3.9: `builtins.tuple` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

`typing.``Union`

  Tipo unión; `Union[X, Y]` significa que o bien X o bien Y.

  Para definir una unión, úsese p. ej. `Union[int, str]`. Más detalles:

  - Los argumentos deben ser tipos y haber al menos uno.

  - Las uniones de uniones se simplifican (se aplanan), p. ej.:

        Union[Union[int, str], float] == Union[int, str, float]

  - Las uniones con un solo argumento se eliminan, p. ej.:

        Union[int] == int  # The constructor actually returns int

  - Argumentos repetidos se omiten, p. ej.:

        Union[int, str, int] == Union[int, str]

  - Cuando se comparan uniones, el orden de los argumentos se ignoran, p. ej.:

        Union[int, str] == Union[str, int]

  - No se puede derivar (subclass) o instanciar una unión.

  - No es posible escribir `Union[X][Y]`.

  - Se puede usar `Optional[X]` como una versión corta de `Union[X, None]`.

  Distinto en la versión 3.7: No elimina subclases explícitas de una unión en tiempo de ejecución.

`typing.``Optional`

  Tipo Optional.

  `Optional[X]` es equivalente a `Union[X, None]`.

  Nótese que no es lo mismo que un argumento opcional, que es aquel que tiene un valor por defecto. Un argumento opcional con un valor por defecto no necesita el indicador `Optional` en su anotación de tipo simplemente por que sea opcional. Por ejemplo:

      def foo(arg: int = 0) -> None:
          ...

  Por otro lado, si se permite un valor `None`, es apropiado el uso de `Optional`, independientemente de que sea opcional o no. Por ejemplo:

      def foo(arg: Optional[int] = None) -> None:
          ...

`typing.``Callable`

  Tipo Callable (invocable); `Callable[[int], str]` es una función de (int) -> str.

  La sintaxis de subscripción (con corchetes []) debe usarse siempre con dos valores: la lista de argumentos y el tipo de retorno. La lista de argumentos debe ser una lista de tipos o unos puntos suspensivos; el tipo de retorno debe ser un único tipo.

  No existe una sintaxis para indicar argumentos opcionales o con clave (keyword); tales funciones rara vez se utilizan como tipos para llamadas. `Callable[..., ReturnType]` (puntos suspensivos) se puede usar para indicar que un callable admite un número indeterminado de argumentos y retorna `ReturnType`. Un simple `Callable` es equivalente a `Callable[..., Any]` y, a su vez, a `collections.abc.Callable`.

  Obsoleto desde la versión 3.9: `collections.abc.Callable` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``Type`(Generic[CT_co])

  Una variable indicada como `C` puede aceptar valores de tipo `C`. Sin embargo, un variable indicada como `Type[C]` puede aceptar valores que son clases en sí mismas – específicamente, aceptará el objecto clase de `C`. Por ejemplo.:

      a = 3         # Has type 'int'
      b = int       # Has type 'Type[int]'
      c = type(a)   # Also has type 'Type[int]'

  Nótese que `Type[C]` es covariante:

      class User: ...
      class BasicUser(User): ...
      class ProUser(User): ...
      class TeamUser(User): ...

      # Accepts User, BasicUser, ProUser, TeamUser, ...
      def make_new_user(user_class: Type[User]) -> User:
          # ...
          return user_class()

  El hecho de que `Type[C]` sea covariante implica que todas las subclases de `C` deben implementar la misma interfaz del constructor y las mismas interfaces de los métodos de clase que `C`. El validador de tipos marcará cualquier incumplimiento de esto, pero permitirá llamadas al constructor que coincida con la llamada al constructor de la clase base indicada. El modo en que el validador de tipos debe gestionar este caso particular podría cambiar en futuras revisiones de PEP 484.

  Lo únicos parámetros válidos de `Type` son clases, `Any`, type variables, y uniones de cualquiera de los tipos anteriores. Por ejemplo:

      def new_non_team_user(user_class: Type[Union[BasicUser, ProUser]]): ...

  `Type[Any]` es equivalente a `Type`, que a su vez es equivalente a `type`, que es la raíz de la jerarquía de metaclases de Python.

  Nuevo en la versión 3.5.2.

  Obsoleto desde la versión 3.9: `builtins.type` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

`typing.``Literal`

  Un tipo que puede ser utilizado para indicar a los validadores de tipos que una variable o un parámetro de una función tiene un valor equivalente al valor literal proveído (o uno de los proveídos). Por ejemplo:

      def validate_simple(data: Any) -> Literal[True]:  # always returns True
          ...

      MODE = Literal['r', 'rb', 'w', 'wb']
      def open_helper(file: str, mode: MODE) -> str:
          ...

      open_helper('/some/path', 'r')  # Passes type check
      open_helper('/other/path', 'typo')  # Error in type checker

  `Literal[...]` no puede ser derivado. En tiempo de ejecución, se permite un valor arbitrario como argumento de tipo de `Literal[...]`, pero los validadores de tipos pueden imponer sus restricciones. Véase PEP 585 para más detalles sobre tipos literales.

  Nuevo en la versión 3.8.

  Distinto en la versión 3.9.1: `Literal` now de-duplicates parameters. Equality comparisons of `Literal` objects are no longer order dependent. `Literal` objects will now raise a `TypeError` exception during equality comparisons if one of their parameters are not hashable.

`typing.``ClassVar`

  Construcción especial para tipado para marcar variables de clase.

  Tal y como introduce PEP 526, una anotación de variable rodeada por ClassVar indica que la intención de un atributo dado es ser usado como variable de clase y que no debería ser modificado en las instancias de esa misma clase. Uso:

      class Starship:
          stats: ClassVar[dict[str, int]] = {} # class variable
          damage: int = 10                     # instance variable

  `ClassVar` solo acepta tipos y no admite más niveles de subíndices.

  `ClassVar` no es un clase en sí misma, y no debe ser usado con `isinstance()` o `issubclass()`. `ClassVar` no modifica el comportamiento de Python en tiempo de ejecución pero puede ser utilizado por validadores de terceros. Por ejemplo, un validador de tipos puede marcar el siguiente código como erróneo:

      enterprise_d = Starship(3000)
      enterprise_d.stats = {} # Error, setting class variable on instance
      Starship.stats = {}     # This is OK

  Nuevo en la versión 3.5.3.

`typing.``Final`

  Un construcción especial para tipado que indica a los validadores de tipo que un nombre no puede ser reasignado o sobrescrito en una subclase. Por ejemplo:

      MAX_SIZE: Final = 9000
      MAX_SIZE += 1  # Error reported by type checker

      class Connection:
          TIMEOUT: Final[int] = 10

      class FastConnector(Connection):
          TIMEOUT = 1  # Error reported by type checker

  No hay comprobación en tiempo de ejecución para estas propiedades. Véase PEP 591 para más detalles.

  Nuevo en la versión 3.8.

`typing.``Annotated`

  A type, introduced in PEP 593 (`Flexible function and variable annotations`), to decorate existing types with context-specific metadata (possibly multiple pieces of it, as `Annotated` is variadic). Specifically, a type `T` can be annotated with metadata `x` via the typehint `Annotated[T, x]`. This metadata can be used for either static analysis or at runtime. If a library (or tool) encounters a typehint `Annotated[T, x]` and has no special logic for metadata `x`, it should ignore it and simply treat the type as `T`. Unlike the `no_type_check` functionality that currently exists in the `typing` module which completely disables typechecking annotations on a function or a class, the `Annotated` type allows for both static typechecking of `T` (which can safely ignore `x`) together with runtime access to `x` within a specific application.

  En última instancia, la responsabilidad de cómo interpretar las anotaciones (si es que la hay) es de la herramienta o librería que encuentra el tipo `Annotated`. Una herramienta o librería que encuentra un tipo `Annotated` puede escanear las anotaciones para determinar si son de interés. (por ejemplo, usando `isinstance()`).

  Cuando una herramienta o librería no soporta anotaciones o encuentra una anotación desconocida, simplemente debe ignorarla o tratar la anotación como el tipo subyacente.

  Depende de la herramienta que consume las anotaciones decidir si el cliente puede tener varias anotaciones en un tipo y cómo combinar esas anotaciones.

  Dado que el tipo `Annotated` permite colocar varias anotaciones del mismo (o diferente) tipo(s) en cualquier nodo, las herramientas o librerías que consumen dichas anotaciones están a cargo de ocuparse de potenciales duplicados. Por ejemplo, si se está realizando un análisis de rango, esto se debería permitir:

      T1 = Annotated[int, ValueRange(-10, 5)]
      T2 = Annotated[T1, ValueRange(-20, 3)]

  Pasar `include_extras=True` a `get_type_hints()` permite acceder a las anotaciones extra en tiempo de ejecución.

  Los detalles de la sintaxis:

  - El primer argumento en `Annotated` debe ser un tipo válido

  - Se permiten varias anotaciones de tipo (`Annotated` admite argumentos variádicos):

        Annotated[int, ValueRange(3, 10), ctype("char")]

  - `Annotated` debe ser llamado con al menos dos argumentos (`Annotated[int]` no es válido)

  - Se mantiene el orden de las anotaciones y se toma en cuenta para chequeos de igualdad:

        Annotated[int, ValueRange(3, 10), ctype("char")] != Annotated[
            int, ctype("char"), ValueRange(3, 10)
        ]

  - Los tipos `Annotated` anidados son aplanados con los metadatos ordenados empezando por la anotación más interna:

        Annotated[Annotated[int, ValueRange(3, 10)], ctype("char")] == Annotated[
            int, ValueRange(3, 10), ctype("char")
        ]

  - Anotaciones duplicadas no son removidas:

        Annotated[int, ValueRange(3, 10)] != Annotated[
            int, ValueRange(3, 10), ValueRange(3, 10)
        ]

  - `Anotated` puede ser usado con alias anidados y genéricos:

        T = TypeVar('T')
        Vec = Annotated[list[tuple[T, T]], MaxLen(10)]
        V = Vec[int]

        V == Annotated[list[tuple[int, int]], MaxLen(10)]

  Nuevo en la versión 3.9.

#### Tipos de construcción de genéricos

Estos no son utilizados en anotaciones. Son utilizados como bloques para crear tipos genéricos.

class `typing.``Generic`

  Clase base abstracta para tipos genéricos.

  Un tipo genérico se declara habitualmente heredando de una instancia de esta clase con una o más variables de tipo. Por ejemplo, un tipo de mapeo genérico se podría definir como:

      class Mapping(Generic[KT, VT]):
          def __getitem__(self, key: KT) -> VT:
              ...
              # Etc.

  Entonces, esta clase se puede usar como sigue:

      X = TypeVar('X')
      Y = TypeVar('Y')

      def lookup_name(mapping: Mapping[X, Y], key: X, default: Y) -> Y:
          try:
              return mapping[key]
          except KeyError:
              return default

class `typing.``TypeVar`

  Variable de tipo.

  Uso:

      T = TypeVar('T')  # Can be anything
      S = TypeVar('S', bound=str)  # Can be any subtype of str
      A = TypeVar('A', str, bytes)  # Must be exactly str or bytes

  Las variables de tipo son principalmente para ayudar a los validadores estáticos de tipos. Sirven tanto como de parámetros para tipos genéricos como para definición de funciones genéricas. Véase `Generic` para más información sobre tipos genéricos. Las funciones genéricas funcionan de la siguiente manera:

      def repeat(x: T, n: int) -> Sequence[T]:
          """Return a list containing n references to x."""
          return [x]*n

      def print_capitalized(x: S) -> S:
          """Print x capitalized, and return x."""
          print(x.capitalize())
          return x

      def concatenate(x: A, y: A) -> A:
          """Add two strings or bytes objects together."""
          return x + y

  Note that type variables can be bound, constrained, or neither, but cannot be both bound and constrained.

  Constrained type variables and bound type variables have different semantics in several important ways. Using a constrained type variable means that the `TypeVar` can only ever be solved as being exactly one of the constraints given:

      a = concatenate('one', 'two')  # Ok, variable 'a' has type 'str'
      b = concatenate(StringSubclass('one'), StringSubclass('two'))  # Inferred type of variable 'b' is 'str',
                                                                     # despite 'StringSubclass' being passed in
      c = concatenate('one', b'two')  # error: type variable 'A' can be either 'str' or 'bytes' in a function call, but not both

  Using a bound type variable, however, means that the `TypeVar` will be solved using the most specific type possible:

      print_capitalized('a string')  # Ok, output has type 'str'

      class StringSubclass(str):
          pass

      print_capitalized(StringSubclass('another string'))  # Ok, output has type 'StringSubclass'
      print_capitalized(45)  # error: int is not a subtype of str

  Type variables can be bound to concrete types, abstract types (ABCs or protocols), and even unions of types:

      U = TypeVar('U', bound=str|bytes)  # Can be any subtype of the union str|bytes
      V = TypeVar('V', bound=SupportsAbs)  # Can be anything with an __abs__ method

  Bound type variables are particularly useful for annotating `classmethods` that serve as alternative constructors. In the following example (© Raymond Hettinger), the type variable `C` is bound to the `Circle` class through the use of a forward reference. Using this type variable to annotate the `with_circumference` classmethod, rather than hardcoding the return type as `Circle`, means that a type checker can correctly infer the return type even if the method is called on a subclass:

      import math

      C = TypeVar('C', bound='Circle')

      class Circle:
          """An abstract circle"""

          def __init__(self, radius: float) -> None:
              self.radius = radius

          # Use a type variable to show that the return type
          # will always be an instance of whatever ``cls`` is
          @classmethod
          def with_circumference(cls: type[C], circumference: float) -> C:
              """Create a circle with the specified circumference"""
              radius = circumference / (math.pi * 2)
              return cls(radius)

      class Tire(Circle):
          """A specialised circle (made out of rubber)"""

          MATERIAL = 'rubber'

      c = Circle.with_circumference(3)  # Ok, variable 'c' has type 'Circle'
      t = Tire.with_circumference(4)  # Ok, variable 't' has type 'Tire' (not 'Circle')

  En tiempo de ejecución, `isinstance(x, T)` lanzará una excepción `TypeError`. En general, `isinstance()` y `issubclass()` no se deben usar con variables de tipo.

  Type variables may be marked covariant or contravariant by passing `covariant=True` or `contravariant=True`. See PEP 484 for more details. By default, type variables are invariant.

`typing.``AnyStr`

  `AnyStr` is a `constrained type variable` defined as `AnyStr = TypeVar('AnyStr', str, bytes)`.

  Su objetivo es ser usada por funciones que pueden aceptar cualquier tipo de cadena de texto sin permitir mezclar diferentes tipos al mismo tiempo. Por ejemplo:

      def concat(a: AnyStr, b: AnyStr) -> AnyStr:
          return a + b

      concat(u"foo", u"bar")  # Ok, output has type 'unicode'
      concat(b"foo", b"bar")  # Ok, output has type 'bytes'
      concat(u"foo", b"bar")  # Error, cannot mix unicode and bytes

class `typing.``Protocol`(Generic)

  Clase base para clases protocolo. Las clases protocolo se definen así:

      class Proto(Protocol):
          def meth(self) -> int:
              ...

  Tales clases son usadas principalmente con validadores estáticos de tipos que detectan subtipado estructural (duck-typing estático), por ejemplo:

      class C:
          def meth(self) -> int:
              return 0

      def func(x: Proto) -> int:
          return x.meth()

      func(C())  # Passes static type check

  Véase PEP 544 para más detalles. Las clases protocolo decoradas con `runtime_checkable()` (que se explica más adelante) se comportan como protocolos simplistas en tiempo de ejecución que solo comprueban la presencia de atributos dados, ignorando su firma de tipo.

  Las clases protocolo pueden ser genéricas, por ejemplo:

      class GenProto(Protocol[T]):
          def meth(self) -> T:
              ...

  Nuevo en la versión 3.8.

`@``typing.``runtime_checkable`

  Marca una clase protocolo como aplicable en tiempo de ejecución (lo convierte en un runtime protocol).

  Tal protocolo se puede usar con `isinstance()` y `issubclass()`. Esto lanzará una excepción `TypeError` cuando se aplique a una clase que no es un protocolo. Esto permite una comprobación estructural simple, muy semejante a «one trick ponies» en `collections.abc` con `Iterable`. Por ejemplo:

      @runtime_checkable
      class Closable(Protocol):
          def close(self): ...

      assert isinstance(open('/some/file'), Closable)

  Nota

  `runtime_checkable()` comprobará únicamente la presencia de los métodos requeridos, no sus firmas de tipo! Por ejemplo, `builtins.complex` implementa `__float__()`, por lo cual pasaría la comprobación `issubclass()` contra `SupportsFloat`. Sin embargo, el método `complex.__float__` existe únicamente para lanzar un `TypeError` con un mensaje más informativo.

  Nuevo en la versión 3.8.

#### Otras directivas especiales

Estos no son utilizados en anotaciones. Son utilizados como bloques para crear tipos genéricos.

class `typing.``NamedTuple`

  Versión para anotación de tipos de `collections.namedtuple()`.

  Uso:

      class Employee(NamedTuple):
          name: str
          id: int

  Esto es equivalente a:

      Employee = collections.namedtuple('Employee', ['name', 'id'])

  Para proporcionar a un campo un valor por defecto se puede asignar en el cuerpo de la clase:

      class Employee(NamedTuple):
          name: str
          id: int = 3

      employee = Employee('Guido')
      assert employee.id == 3

  Los campos con un valor por defecto deben ir después de los campos sin valor por defecto.

  The resulting class has an extra attribute `__annotations__` giving a dict that maps the field names to the field types. (The field names are in the `_fields` attribute and the default values are in the `_field_defaults` attribute, both of which are part of the `namedtuple()` API.)

  Las subclases de `NamedTuple` también pueden tener docstrings y métodos:

      class Employee(NamedTuple):
          """Represents an employee."""
          name: str
          id: int = 3

          def __repr__(self) -> str:
              return f'<Employee {self.name}, id={self.id}>'

  Uso retrocompatible:

      Employee = NamedTuple('Employee', [('name', str), ('id', int)])

  Distinto en la versión 3.6: Soporte añadido para la sintaxis de anotación de variables propuesto en PEP 526.

  Distinto en la versión 3.6.1: Soporte añadido para valores por defecto, métodos y docstrings.

  Distinto en la versión 3.8: Los atributos `_field_types` y `__annotations__` son simples diccionarios en vez de instancias de `OrderedDict`.

  Distinto en la versión 3.9: Se remueve el atributo `_field_types` en favor del atributo más estándar `__annotations__` que tiene la misma información.

`typing.``NewType`(name, tp)

  Un función auxiliar para indicar un tipo distinguible a los validadores de tipos, véase NewType. En tiempo de ejecución, retorna una función que retorna su argumento. Uso:

      UserId = NewType('UserId', int)
      first_user = UserId(1)

  Nuevo en la versión 3.5.2.

class `typing.``TypedDict`(dict)

  Es una construcción especial para añadir indicadores de tipo a un diccionario. En tiempo de ejecución es un `dict` simple.

  `TypedDict` crea un tipo de diccionario que espera que todas sus instancias tenga un cierto conjunto de claves, donde cada clave está asociada con un valor de un tipo determinado. Esta exigencia no se comprueba en tiempo de ejecución y solo es aplicada por validadores de tipo. Uso:

      class Point2D(TypedDict):
          x: int
          y: int
          label: str

      a: Point2D = {'x': 1, 'y': 2, 'label': 'good'}  # OK
      b: Point2D = {'z': 3, 'label': 'bad'}           # Fails type check

      assert Point2D(x=1, y=2, label='first') == dict(x=1, y=2, label='first')

  To allow using this feature with older versions of Python that do not support PEP 526, `TypedDict` supports two additional equivalent syntactic forms:

  - Using a literal `dict` as the second argument:

        Point2D = TypedDict('Point2D', {'x': int, 'y': int, 'label': str})

  - Using keyword arguments:

        Point2D = TypedDict('Point2D', x=int, y=int, label=str)

  The functional syntax should also be used when any of the keys are not valid identifiers, for example because they are keywords or contain hyphens. Example:

      # raises SyntaxError
      class Point2D(TypedDict):
          in: int  # 'in' is a keyword
          x-y: int  # name with hyphens

      # OK, functional syntax
      Point2D = TypedDict('Point2D', {'in': int, 'x-y': int})

  By default, all keys must be present in a `TypedDict`. It is possible to override this by specifying totality. Usage:

      class Point2D(TypedDict, total=False):
          x: int
          y: int

      # Alternative syntax
      Point2D = TypedDict('Point2D', {'x': int, 'y': int}, total=False)

  This means that a `Point2D` `TypedDict` can have any of the keys omitted. A type checker is only expected to support a literal `False` or `True` as the value of the `total` argument. `True` is the default, and makes all items defined in the class body required.

  It is possible for a `TypedDict` type to inherit from one or more other `TypedDict` types using the class-based syntax. Usage:

      class Point3D(Point2D):
          z: int

  `Point3D` has three items: `x`, `y` and `z`. It is equivalent to this definition:

      class Point3D(TypedDict):
          x: int
          y: int
          z: int

  A `TypedDict` cannot inherit from a non-`TypedDict` class, notably including `Generic`. For example:

      class X(TypedDict):
          x: int

      class Y(TypedDict):
          y: int

      class Z(object): pass  # A non-TypedDict class

      class XY(X, Y): pass  # OK

      class XZ(X, Z): pass  # raises TypeError

      T = TypeVar('T')
      class XT(X, Generic[T]): pass  # raises TypeError

  A `TypedDict` can be introspected via `__annotations__`, `__total__`, `__required_keys__`, and `__optional_keys__`.

  `__total__`

    `Point2D.__total__` gives the value of the `total` argument. Example:

        >>> from typing import TypedDict
        >>> class Point2D(TypedDict): pass
        >>> Point2D.__total__
        True
        >>> class Point2D(TypedDict, total=False): pass
        >>> Point2D.__total__
        False
        >>> class Point3D(Point2D): pass
        >>> Point3D.__total__
        True

  `__required_keys__`
  `__optional_keys__`

    `Point2D.__required_keys__` and `Point2D.__optional_keys__` return `frozenset` objects containing required and non-required keys, respectively. Currently the only way to declare both required and non-required keys in the same `TypedDict` is mixed inheritance, declaring a `TypedDict` with one value for the `total` argument and then inheriting it from another `TypedDict` with a different value for `total`. Usage:

        >>> class Point2D(TypedDict, total=False):
        ...     x: int
        ...     y: int
        ...
        >>> class Point3D(Point2D):
        ...     z: int
        ...
        >>> Point3D.__required_keys__ == frozenset({'z'})
        True
        >>> Point3D.__optional_keys__ == frozenset({'x', 'y'})
        True

  Véase PEP 589 para más ejemplos y reglas detalladas del uso de `TypedDict`.

  Nuevo en la versión 3.8.

### Colecciones genéricas concretas

#### Correspondientes a tipos integrados

class `typing.``Dict`(dict, MutableMapping[KT, VT])

  Una versión genérica de `dict`. Útil para anotar tipos de retorno. Para anotar argumentos es preferible usar un tipo abstracto de colección como `Mapping`.

  Este tipo se puede usar de la siguiente manera:

      def count_words(text: str) -> Dict[str, int]:
          ...

  Obsoleto desde la versión 3.9: `builtins.dict` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``List`(list, MutableSequence[T])

  Versión genérica de `list`. Útil para anotar tipos de retorno. Para anotar argumentos es preferible usar un tipo abstracto de colección como `Sequence` o `Iterable`.

  Este tipo se puede usar del siguiente modo:

      T = TypeVar('T', int, float)

      def vec2(x: T, y: T) -> List[T]:
          return [x, y]

      def keep_positives(vector: Sequence[T]) -> List[T]:
          return [item for item in vector if item > 0]

  Obsoleto desde la versión 3.9: `builtins.list` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``Set`(set, MutableSet[T])

  Una versión genérica de `builtins.set`. Útil para anotar tipos de retornos. Para anotar argumentos es preferible usar un tipo abstracto de colección como `AbstractSet`.

  Obsoleto desde la versión 3.9: `builtins.set` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``FrozenSet`(frozenset, AbstractSet[T_co])

  Una versión genérica de `builtins.frozenset`.

  Obsoleto desde la versión 3.9: `builtins.frozenset` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

Nota

`Tuple` es una forma especial.

#### Correspondiente a tipos en `collections`

class `typing.``DefaultDict`(collections.defaultdict, MutableMapping[KT, VT])

  Una versión genérica de `collections.defaultdict`.

  Nuevo en la versión 3.5.2.

  Obsoleto desde la versión 3.9: `collections.defaultdict` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``OrderedDict`(collections.OrderedDict, MutableMapping[KT, VT])

  Una versión genérica de `collections.OrderedDict`.

  Nuevo en la versión 3.7.2.

  Obsoleto desde la versión 3.9: `collections.OrderedDict` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``ChainMap`(collections.ChainMap, MutableMapping[KT, VT])

  Una versión genérica de `collections.ChainMap`.

  Nuevo en la versión 3.5.4.

  Nuevo en la versión 3.6.1.

  Obsoleto desde la versión 3.9: `collections.ChainMap` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``Counter`(collections.Counter, Dict[T, int])

  Una versión genérica de `collections.Counter`.

  Nuevo en la versión 3.5.4.

  Nuevo en la versión 3.6.1.

  Obsoleto desde la versión 3.9: `collections.Counter` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``Deque`(deque, MutableSequence[T])

  Una versión genérica de `collections.deque`.

  Nuevo en la versión 3.5.4.

  Nuevo en la versión 3.6.1.

  Obsoleto desde la versión 3.9: `collections.deque` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

#### Otros tipos concretos

class `typing.``IO`
class `typing.``TextIO`
class `typing.``BinaryIO`

  Generic type `IO[AnyStr]` and its subclasses `TextIO(IO[str])` and `BinaryIO(IO[bytes])` represent the types of I/O streams such as returned by `open()`.

  Deprecated since version 3.8, will be removed in version 3.12: These types are also in the `typing.io` namespace, which was never supported by type checkers and will be removed.

class `typing.``Pattern`
class `typing.``Match`

  These type aliases correspond to the return types from `re.compile()` and `re.match()`. These types (and the corresponding functions) are generic in `AnyStr` and can be made specific by writing `Pattern[str]`, `Pattern[bytes]`, `Match[str]`, or `Match[bytes]`.

  Deprecated since version 3.8, will be removed in version 3.12: These types are also in the `typing.re` namespace, which was never supported by type checkers and will be removed.

  Obsoleto desde la versión 3.9: Las clases `Pattern` y `Match` de `re` ahora soportan `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``Text`

  `Text` es un alias para `str`. Ésta disponible para proporcionar un mecanismo compatible hacia delante para código en Python 2: en Python 2, `Text` es un alias de `unicode`.

  Úsese `Text` para indicar que un valor debe contener una cadena de texto Unicode de manera que sea compatible con Python 2 y Python 3:

      def add_unicode_checkmark(text: Text) -> Text:
          return text + u' \u2713'

  Nuevo en la versión 3.5.2.

### Clase base abstracta para tipos genéricos

#### Correspondientes a las colecciones en `collections.abc`

class `typing.``AbstractSet`(Sized, Collection[T_co])

  Una versión genérica de `collections.abc.Set`.

  Obsoleto desde la versión 3.9: `collections.abc.Set` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``ByteString`(Sequence[int])

  Una versión genérica de `collections.abc.ByteString`.

  Este tipo representa a los tipos `bytes`, `bytearray`, y `memoryview` de secuencias de bytes.

  Como abreviación para este tipo, `bytes` se puede usar para anotar argumentos de cualquiera de los tipos mencionados arriba.

  Obsoleto desde la versión 3.9: `collections.abc.ByteString` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``Collection`(Sized, Iterable[T_co], Container[T_co])

  Una versión genérica de `collections.abc.Collection`

  Nuevo en la versión 3.6.0.

  Obsoleto desde la versión 3.9: `collections.abc.Collection` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``Container`(Generic[T_co])

  Una versión genérica de `collections.abc.Container`.

  Obsoleto desde la versión 3.9: `collections.abc.Container` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``ItemsView`(MappingView, Generic[KT_co, VT_co])

  Una versión genérica de `collections.abc.ItemsView`.

  Obsoleto desde la versión 3.9: `collections.abc.ItemsView` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``KeysView`(MappingView[KT_co], AbstractSet[KT_co])

  Una versión genérica de `collections.abc.KeysView`.

  Obsoleto desde la versión 3.9: `collections.abc.KeysView` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``Mapping`(Sized, Collection[KT], Generic[VT_co])

  Una versión genérica de `collections.abc.Mapping`. Este tipo se puede usar de la siguiente manera:

      def get_position_in_index(word_list: Mapping[str, int], word: str) -> int:
          return word_list[word]

  Obsoleto desde la versión 3.9: `collections.abc.Mapping` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``MappingView`(Sized, Iterable[T_co])

  Una versión genérica de `collections.abc.MappingView`.

  Obsoleto desde la versión 3.9: `collections.abc.MappingView` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``MutableMapping`(Mapping[KT, VT])

  Una versión genérica de `collections.abc.MutableMapping`.

  Obsoleto desde la versión 3.9: `collections.abc.MutableMapping` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``MutableSequence`(Sequence[T])

  Una versión genérica de `collections.abc.MutableSequence`.

  Obsoleto desde la versión 3.9: `collections.abc.MutableSequence` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``MutableSet`(AbstractSet[T])

  Una versión genérica de `collections.abc.MutableSet`.

  Obsoleto desde la versión 3.9: `collections.abc.MutableSet` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``Sequence`(Reversible[T_co], Collection[T_co])

  Una versión genérica de `collections.abc.Sequence`.

  Obsoleto desde la versión 3.9: `collections.abc.Sequence` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``ValuesView`(MappingView[VT_co])

  Una versión genérica de `collections.abc.ValuesView`.

  Obsoleto desde la versión 3.9: `collections.abc.ValuesView` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

#### Correspondiente a otros tipos en `collections.abc`

class `typing.``Iterable`(Generic[T_co])

  Una versión genérica de `collections.abc.Iterable`.

  Obsoleto desde la versión 3.9: `collections.abc.Iterable` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``Iterator`(Iterable[T_co])

  Una versión genérica de `collections.abc.Iterator`.

  Obsoleto desde la versión 3.9: `collections.abc.Iterator` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``Generator`(Iterator[T_co], Generic[T_co, T_contra, V_co])

  Un generador puede ser anotado con el tipo genérico `Generator[YieldType, SendType, ReturnType]`. Por ejemplo:

      def echo_round() -> Generator[int, float, str]:
          sent = yield 0
          while sent >= 0:
              sent = yield round(sent)
          return 'Done'

  Nótese que en contraste con muchos otros genéricos en el módulo typing, el `SendType` de `Generator` se comporta como contravariante, no covariante ni invariante.

  Si tu generador solo retornará valores con yield, establece `SendType` y `ReturnType` como `None`:

      def infinite_stream(start: int) -> Generator[int, None, None]:
          while True:
              yield start
              start += 1

  Opcionalmente, anota tu generador con un tipo de retorno de `Iterable[YieldType]` o `Iterator[YieldType]`:

      def infinite_stream(start: int) -> Iterator[int]:
          while True:
              yield start
              start += 1

  Obsoleto desde la versión 3.9: `collections.abc.Generator` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``Hashable`

  An alias to `collections.abc.Hashable`.

class `typing.``Reversible`(Iterable[T_co])

  Una versión genérica de `collections.abc.Reversible`.

  Obsoleto desde la versión 3.9: `collections.abc.Reversible` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``Sized`

  An alias to `collections.abc.Sized`.

#### Programación asíncrona

class `typing.``Coroutine`(Awaitable[V_co], Generic[T_co, T_contra, V_co])

  Una versión genérica de `collections.abc.Coroutine`.y orden de las variables de tipo se corresponde con aquellas de `Generator`, por ejemplo:

      from collections.abc import Coroutine
      c: Coroutine[list[str], str, int]  # Some coroutine defined elsewhere
      x = c.send('hi')                   # Inferred type of 'x' is list[str]
      async def bar() -> None:
          y = await c                    # Inferred type of 'y' is int

  Nuevo en la versión 3.5.3.

  Obsoleto desde la versión 3.9: `collections.abc.Coroutine` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``AsyncGenerator`(AsyncIterator[T_co], Generic[T_co, T_contra])

  Un generador asíncrono se puede anotar con el tipo genérico `AsyncGenerator[YieldType, SendType]`. Por ejemplo:

      async def echo_round() -> AsyncGenerator[int, float]:
          sent = yield 0
          while sent >= 0.0:
              rounded = await round(sent)
              sent = yield rounded

  A diferencia de los generadores normales, los generadores asíncronos no pueden retornar un valor, por lo que no hay un parámetro de tipo``ReturnType``. Igual que `Generator`, `SendType` se comporta como contravariante.

  Si tu generador solo retornará valores con yield, establece el `SendType` como `None`:

      async def infinite_stream(start: int) -> AsyncGenerator[int, None]:
          while True:
              yield start
              start = await increment(start)

  Opcionalmente, anota el generador con un tipo de retorno `AsyncIterable[YieldType]` o `AsyncIterator[YieldType]`:

      async def infinite_stream(start: int) -> AsyncIterator[int]:
          while True:
              yield start
              start = await increment(start)

  Nuevo en la versión 3.6.1.

  Obsoleto desde la versión 3.9: `collections.abc.AsycGenerator` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``AsyncIterable`(Generic[T_co])

  Una versión genérica de `collections.abc.AsyncIterable`.

  Nuevo en la versión 3.5.2.

  Obsoleto desde la versión 3.9: `collections.abc.AsyncIterable` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``AsyncIterator`(AsyncIterable[T_co])

  Una versión genérica de `collections.abc.AsyncIterator`.

  Nuevo en la versión 3.5.2.

  Obsoleto desde la versión 3.9: `collections.abc.AsyncIterator` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``Awaitable`(Generic[T_co])

  Una versión genérica de `collections.abc.Awaitable`.

  Nuevo en la versión 3.5.2.

  Obsoleto desde la versión 3.9: `collections.abc.Awaitable` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

#### Tipos del administrador de contextos

class `typing.``ContextManager`(Generic[T_co])

  Una versión genérica de `contextlib.AbstractContextManager`.

  Nuevo en la versión 3.5.4.

  Nuevo en la versión 3.6.0.

  Obsoleto desde la versión 3.9: `contextlib.AbstractContextManager` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

class `typing.``AsyncContextManager`(Generic[T_co])

  Una versión genérica de `contextlib.AbstractAsyncContextManager`.

  Nuevo en la versión 3.5.4.

  Nuevo en la versión 3.6.2.

  Obsoleto desde la versión 3.9: `contextlib.AbstractAsyncContextManager` ahora soporta `[]`. Véase PEP 585 y Tipo Alias Genérico.

### Protocolos

Estos protocolos se decoran con `runtime_checkable()`.

class `typing.``SupportsAbs`

  Una ABC con un método abstracto `__abs__` que es covariante en su tipo retornado.

class `typing.``SupportsBytes`

  Una ABC con un método abstracto `__bytes__`.

class `typing.``SupportsComplex`

  Una ABC con un método abstracto `__complex__`.

class `typing.``SupportsFloat`

  Una ABC con un método abstracto `__float__`.

class `typing.``SupportsIndex`

  Una ABC con un método abstracto `__index__`.

  Nuevo en la versión 3.8.

class `typing.``SupportsInt`

  Una ABC con un método abstracto `__int__`.

class `typing.``SupportsRound`

  Una ABC con un método abstracto `__round__` que es covariantes en su tipo retornado.

### Funciones y decoradores

`typing.``cast`(typ, val)

  Convertir un valor a su tipo.

  Esto retorna el valor sin modificar. Para el validador de tipos esto indica que el valor de retorno tiene el tipo señalado pero, de manera intencionada, no se comprobará en tiempo de ejecución (para maximizar la velocidad).

`@``typing.``overload`

  El decorador `@overload` permite describir funciones y métodos que soportan diferentes combinaciones de tipos de argumento. A una serie de definiciones decoradas con `@overload` debe seguir exactamente una definición no decorada con ``@overload` (para la misma función o método). Las definiciones decoradas con `@overload` son solo para beneficio del validador de tipos, ya que serán sobrescritas por la definición no decorada con `@overload`. Esta última se usa en tiempo de ejecución y debería ser ignorada por el validador de tipos. En tiempo de ejecución, llamar a una función decorada con `@overload` lanzará directamente `NotImplementedError`. Un ejemplo de sobrecarga que proporciona un tipo más preciso se puede expresar con una unión o una variable de tipo:

      @overload
      def process(response: None) -> None:
          ...
      @overload
      def process(response: int) -> tuple[int, str]:
          ...
      @overload
      def process(response: bytes) -> str:
          ...
      def process(response):
          <actual implementation>

  Véase PEP 484 para más detalle, y compárese con otras semánticas de tipado.

`@``typing.``final`

  Un decorador que indica a los validadores de tipos que el método decorado no se puede sobreescribir, o que la clase decorada no se puede derivar (subclassed). Por ejemplo:

      class Base:
          @final
          def done(self) -> None:
              ...
      class Sub(Base):
          def done(self) -> None:  # Error reported by type checker
              ...

      @final
      class Leaf:
          ...
      class Other(Leaf):  # Error reported by type checker
          ...

  No hay comprobación en tiempo de ejecución para estas propiedades. Véase PEP 591 para más detalles.

  Nuevo en la versión 3.8.

`@``typing.``no_type_check`

  Un decorador para indicar que la anotaciones no deben ser comprobadas como indicadores de tipo.

  Esto funciona como un decorator (decorador) de clase o función. Con una clase, se aplica recursivamente a todos los métodos definidos en dichas clase (pero no a lo métodos definidos en sus superclases y subclases).

  Esto modifica la función o funciones in situ.

`@``typing.``no_type_check_decorator`

  Un decorador que asigna a otro decorador el efecto de `no_type_check()` (no comprobar tipo).

  Esto hace que el decorador decorado añada el efecto de `no_type_check()` a la función decorada.

`@``typing.``type_check_only`

  Un decorador que marca una clase o función como no disponible en tiempo de ejecución.

  Este decorador no está disponible en tiempo de ejecución. Existe principalmente para marcar clases que se definen en archivos stub para cuando una implementación retorna una instancia de una clase privada:

      @type_check_only
      class Response:  # private or not available at runtime
          code: int
          def get_header(self, name: str) -> str: ...

      def fetch_response() -> Response: ...

  Nótese que no se recomienda retornar instancias de clases privadas. Normalmente es preferible convertirlas en clases públicas.

### Ayudas de introspección

`typing.``get_type_hints`(obj, globalns=None, localns=None, include_extras=False)

  Retorna un diccionario que contiene indicaciones de tipo para una función, método, módulo o objeto clase.

  Habitualmente, esto es lo mismo que `obj.__annotations__`. Además, las referencias indicadas como cadenas de texto se gestionan evaluándolas en los espacios de nombres``globals`` y `locals`. Si es necesario, se añade``Optional[t]`` para anotar una función o método, si se establece `None` como valor por defecto. Para una clase `C`, se retorna un diccionario construido por la combinación de `__annotations__` y `C.__mro` en orden inverso.

  La función reemplaza todos los `Annotated[T, ...]` con `T` de manera recursiva, a menos que `include_extras` se defina como `True` ( véase `Annotated` para más información). Por ejemplo:

      class Student(NamedTuple):
          name: Annotated[str, 'some marker']

      get_type_hints(Student) == {'name': str}
      get_type_hints(Student, include_extras=False) == {'name': str}
      get_type_hints(Student, include_extras=True) == {
          'name': Annotated[str, 'some marker']
      }

  Distinto en la versión 3.9: Se agregan los parámetros `include_extras` como parte de PEP 593.

`typing.``get_args`(tp)

`typing.``get_origin`(tp)

  Provee introspección básica para tipos genéricos y construcciones especiales de tipado.

  Para un objeto de tipado de la forma `X[Y,Z, ...]`, estas funciones retornan `X` y `(Y, Z, ...)`. Si `X` es un alias genérico para una clase integrada o una clase de `collections`, se normaliza a su clase original. Si `X` es una `Union` o `Literal` contenidos en otro tipo genérico, el orden de `(Y, Z, ...)` podría ser distinto al orden de los argumentos originales `[Y, Z, ...]` debido al cacheo de tipos. Los objetos no soportados retornan `None` y `()` correspondientemente. Ejemplos:

      assert get_origin(Dict[str, int]) is dict
      assert get_args(Dict[int, str]) == (int, str)

      assert get_origin(Union[int, str]) is Union
      assert get_args(Union[int, str]) == (int, str)

  Nuevo en la versión 3.8.

class `typing.``ForwardRef`

  A class used for internal typing representation of string forward references. For example, `List["SomeClass"]` is implicitly transformed into `List[ForwardRef("SomeClass")]`. This class should not be instantiated by a user, but may be used by introspection tools.

  Nota

  PEP 585 generic types such as `list["SomeClass"]` will not be implicitly transformed into `list[ForwardRef("SomeClass")]` and thus will not automatically resolve to `list[SomeClass]`.

  Nuevo en la versión 3.7.4.

### Constantes

`typing.``TYPE_CHECKING`

  Una constante especial que se asume como cierta (`True`) por validadores estáticos de tipos de terceros. Es falsa (`False`) en tiempo de ejecución. Uso:

      if TYPE_CHECKING:
          import expensive_mod

      def fun(arg: 'expensive_mod.SomeType') -> None:
          local_var: expensive_mod.AnotherType = other_fun()

  Nótese que la primera anotación de tipo debe estar rodeada por comillas, convirtiéndola en una «referencia directa», para ocultar al intérprete la referencia `expensive_mod` en tiempo de ejecución. Las anotaciones de tipo para variables locales no se evalúan, así que la segunda anotación no necesita comillas.

  Nota

  If `from __future__ import annotations` is used, annotations are not evaluated at function definition time. Instead, they are stored as strings in `__annotations__`. This makes it unnecessary to use quotes around the annotation (see PEP 563).

  Nuevo en la versión 3.5.2.