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

Ver también:

  For a quick overview of type hints, refer to this cheat sheet.

  The "Type System Reference" section of https://mypy.readthedocs.io/
  -- since the Python typing system is standardised via PEPs, this
  reference should broadly apply to most Python type checkers,
  although some parts may still be specific to mypy.

  The documentation at https://typing.readthedocs.io/ serves as useful
  reference for type system features, useful typing related tools and
  typing best practices.


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"

* **PEP 604**: Allow writing union types as "X | Y"
     *Introducing* "types.UnionType" and the ability to use the
     binary-or operator "|" to signify a union of types

* **PEP 612**: Parameter Specification Variables
     *Introducing* "ParamSpec" and "Concatenate"

* **PEP 613**: Explicit Type Aliases
     *Introducing* "TypeAlias"

* **PEP 647**: User-Defined Type Guards
     *Introducing* "TypeGuard"


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]

   # passes type checking; 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:
       ...

   # passes type checking
   user_a = get_user_name(UserId(42351))

   # fails type checking; 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 much 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.

No es válido crear un subtipo de "Derived":

   from typing import NewType

   UserId = NewType('UserId', int)

   # Fails at runtime and does not pass type checking
   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.

Distinto en la versión 3.10: "NewType" es ahora una clase en lugar de
una función. Existe un costo de tiempo de ejecución adicional cuando
se llama a "NewType" a través de una función normal. Sin embargo, este
costo se reducirá en 3.11.0.


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]".

Los invocables que toman otros invocables como argumentos pueden
indicar que sus tipos de parámetros dependen unos de otros utilizando
"ParamSpec". Además, si ese invocable agrega o elimina argumentos de
otros invocables, se puede utilizar el operador "Concatenate". Toman
la forma "Callable[ParamSpecVariable, ReturnType]" y
"Callable[Concatenate[Arg1Type, Arg2Type, ..., ParamSpecVariable],
ReturnType]" respectivamente.

Distinto en la versión 3.10: "Callable" now supports "ParamSpec" and
"Concatenate". See **PEP 612** for more details.

Ver también:

  The documentation for "ParamSpec" and "Concatenate" provides
  examples of usage in "Callable".


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
   S = TypeVar('S')
   Response = Iterable[S] | int

   # Return type here is same as 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.

Los genéricos definidos por el usuario para expresiones de parámetros
también se admiten a través de variables de especificación de
parámetros con el formato "Generic[P]". El comportamiento es coherente
con las variables de tipo descritas anteriormente, ya que el módulo
typing trata las variables de especificación de parámetros como una
variable de tipo especializada. La única excepción a esto es que se
puede usar una lista de tipos para sustituir un "ParamSpec":

   >>> from typing import Generic, ParamSpec, TypeVar

   >>> T = TypeVar('T')
   >>> P = ParamSpec('P')

   >>> class Z(Generic[T, P]): ...
   ...
   >>> Z[int, [dict, float]]
   __main__.Z[int, (<class 'dict'>, <class 'float'>)]

Furthermore, a generic with only one parameter specification variable
will accept parameter lists in the forms "X[[Type1, Type2, ...]]" and
also "X[Type1, Type2, ...]" for aesthetic reasons.  Internally, the
latter is converted to the former, so the following are equivalent:

   >>> class X(Generic[P]): ...
   ...
   >>> X[int, str]
   __main__.X[(<class 'int'>, <class 'str'>)]
   >>> X[[int, str]]
   __main__.X[(<class 'int'>, <class 'str'>)]

Tenga en cuenta que los genéricos con "ParamSpec" pueden no tener el
"__parameters__" correcto después de la sustitución en algunos casos
porque están destinados principalmente a la verificación de tipos
estáticos.

Distinto en la versión 3.10: "Generic" ahora se puede parametrizar
sobre expresiones de parámetros. Consulte "ParamSpec" y **PEP 612**
para obtener más detalles.

A user-defined generic class can have ABCs as base classes without a
metaclass conflict. Generic metaclasses are not supported. The outcome
of parameterizing generics is cached, and most types in the typing
module are *hashable* and comparable for 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:
       # Passes type checking; 'item' could be any type,
       # and that type might have a 'bar' method
       item.bar()
       ...

Notice that no type checking is performed when assigning a value of
type "Any" to a more precise type. For example, the static type
checker did not report an error when assigning "a" to "s" even though
"s" was declared to be of type "str" and receives an "int" value at
runtime!

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 type checking; an object does not have a 'magic' method.
       item.magic()
       ...

   def hash_b(item: Any) -> int:
       # Passes type checking
       item.magic()
       ...

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

   # Passes type checking, 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.

typing.TypeAlias

   Anotación especial para declarar explícitamente un alias de tipo.
   Por ejemplo:

      from typing import TypeAlias

      Factors: TypeAlias = list[int]

   Consulte **PEP 613** para obtener más detalles sobre los alias de
   tipos explícitos.

   Nuevo en la versión 3.10.


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" now supports
   subscripting ("[]"). See **PEP 585** and Tipo Alias Genérico.

typing.Union

   Tipo de unión; "Union[X, Y]" es equivalente a "X | Y" y significa X
   o Y.

   To define a union, use e.g. "Union[int, str]" or the shorthand "int
   | str". Using that shorthand is recommended. Details:

   * 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] == int | str

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

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

   * No puede crear una subclase o instanciar un "Union".

   * No es posible escribir "Union[X][Y]".

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

   Distinto en la versión 3.10: Las uniones ahora se pueden escribir
   como "X | Y". Consulte union type expressions.

typing.Optional

   Tipo Optional.

   "Optional[X]" es equivalente a "X | None" (o "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:
          ...

   Distinto en la versión 3.10: Optional ahora se puede escribir como
   "X | None". Consulte union type expressions.

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

   Los invocables que toman otros invocables como argumentos pueden
   indicar que sus tipos de parámetros dependen unos de otros
   utilizando "ParamSpec". Además, si ese invocable agrega o elimina
   argumentos de otros invocables, se puede utilizar el operador
   "Concatenate". Toman la forma "Callable[ParamSpecVariable,
   ReturnType]" y "Callable[Concatenate[Arg1Type, Arg2Type, ...,
   ParamSpecVariable], ReturnType]" respectivamente.

   Obsoleto desde la versión 3.9: "collections.abc.Callable" now
   supports subscripting ("[]"). See **PEP 585** and Tipo Alias
   Genérico.

   Distinto en la versión 3.10: "Callable" now supports "ParamSpec"
   and "Concatenate". See **PEP 612** for more details.

   Ver también:

     La documentación de "ParamSpec" y "Concatenate" proporciona
     ejemplos de uso con "Callable".

typing.Concatenate

   Se utiliza con "Callable" y "ParamSpec" para escribir anotar un
   invocable de orden superior que agrega, elimina o transforma
   parámetros de otro invocable. El uso tiene el formato
   "Concatenate[Arg1Type, Arg2Type, ..., ParamSpecVariable]".
   Actualmente, "Concatenate" solo es válido cuando se utiliza como
   primer argumento de un "Callable". El último parámetro de
   "Concatenate" debe ser un "ParamSpec".

   Por ejemplo, para anotar un decorador "with_lock" que proporciona
   un "threading.Lock" a la función decorada, "Concatenate" puede
   usarse para indicar que "with_lock" espera un invocable que toma un
   "Lock" como primer argumento y retorna un invocable con un tipo de
   firma diferente. En este caso, el "ParamSpec" indica que los tipos
   de parámetros de los invocables retornados dependen de los tipos de
   parámetros de los invocables que se pasan en

      from collections.abc import Callable
      from threading import Lock
      from typing import Concatenate, ParamSpec, TypeVar

      P = ParamSpec('P')
      R = TypeVar('R')

      # Use this lock to ensure that only one thread is executing a function
      # at any time.
      my_lock = Lock()

      def with_lock(f: Callable[Concatenate[Lock, P], R]) -> Callable[P, R]:
          '''A type-safe decorator which provides a lock.'''
          def inner(*args: P.args, **kwargs: P.kwargs) -> R:
              # Provide the lock as the first argument.
              return f(my_lock, *args, **kwargs)
          return inner

      @with_lock
      def sum_threadsafe(lock: Lock, numbers: list[float]) -> float:
          '''Add a list of numbers together in a thread-safe manner.'''
          with lock:
              return sum(numbers)

      # We don't need to pass in the lock ourselves thanks to the decorator.
      sum_threadsafe([1.1, 2.2, 3.3])

Nuevo en la versión 3.10.

Ver también:

  * **PEP 612** - Variables de especificación de parámetros (el PEP
    que introdujo "ParamSpec" y "Concatenate").

  * "ParamSpec" y "Callable".

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
   *objeto 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[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" now supports
   subscripting ("[]"). See **PEP 585** and 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" ahora elimina los
   parámetros duplicados. Las comparaciones de igualdad de los objetos
   "Literal" ya no dependen del orden. Los objetos "Literal" ahora
   lanzarán una excepción "TypeError" durante las comparaciones de
   igualdad si uno de sus parámetros no es *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.

typing.TypeGuard

   Formulario de mecanografía especial utilizado para anotar el tipo
   de retorno de una función de protección de tipo definida por el
   usuario. "TypeGuard" solo acepta un argumento de tipo único. En
   tiempo de ejecución, las funciones marcadas de esta manera deberían
   retornar un booleano.

   "TypeGuard" tiene como objetivo beneficiar a *type narrowing*, una
   técnica utilizada por los verificadores de tipo estático para
   determinar un tipo más preciso de una expresión dentro del flujo de
   código de un programa. Por lo general, el estrechamiento de tipos
   se realiza analizando el flujo de código condicional y aplicando el
   estrechamiento a un bloque de código. La expresión condicional aquí
   a veces se denomina "protección de tipo":

      def is_str(val: str | float):
          # "isinstance" type guard
          if isinstance(val, str):
              # Type of ``val`` is narrowed to ``str``
              ...
          else:
              # Else, type of ``val`` is narrowed to ``float``.
              ...

   A veces sería conveniente utilizar una función booleana definida
   por el usuario como protección de tipos. Dicha función debería usar
   "TypeGuard[...]" como su tipo de retorno para alertar a los
   verificadores de tipo estático sobre esta intención.

   El uso de "-> TypeGuard" le dice al verificador de tipo estático
   que para una función determinada:

   1. El valor de retorno es un booleano.

   2. Si el valor de retorno es "True", el tipo de su argumento es el
      tipo dentro de "TypeGuard".

   Por ejemplo:

      def is_str_list(val: List[object]) -> TypeGuard[List[str]]:
          '''Determines whether all objects in the list are strings'''
          return all(isinstance(x, str) for x in val)

      def func1(val: List[object]):
          if is_str_list(val):
              # Type of ``val`` is narrowed to ``List[str]``.
              print(" ".join(val))
          else:
              # Type of ``val`` remains as ``List[object]``.
              print("Not a list of strings!")

   Si "is_str_list" es un método de clase o instancia, entonces el
   tipo en "TypeGuard" se asigna al tipo del segundo parámetro después
   de "cls" o "self".

   En resumen, la forma "def foo(arg: TypeA) -> TypeGuard[TypeB]: ..."
   significa que si "foo(arg)" retorna "True", entonces "arg" se
   estrecha de "TypeA" a "TypeB".

   Nota:

     No es necesario que "TypeB" sea una forma más estrecha de
     "TypeA"; incluso puede ser una forma más amplia. La razón
     principal es permitir cosas como reducir "List[object]" a
     "List[str]" aunque este último no sea un subtipo del primero, ya
     que "List" es invariante. La responsabilidad de escribir
     protecciones de tipo seguro se deja al usuario.

   "TypeGuard" also works with type variables.  See **PEP 647** for
   more details.

   Nuevo en la versión 3.10.


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 (by 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.

class typing.ParamSpec(name, *, bound=None, covariant=False, contravariant=False)

   Variable de especificación de parámetros. Una versión especializada
   de "type variables".

   Uso:

      P = ParamSpec('P')

   Las variables de especificación de parámetros existen
   principalmente para el beneficio de los verificadores de tipo
   estático. Se utilizan para reenviar los tipos de parámetros de un
   invocable a otro invocable, un patrón que se encuentra comúnmente
   en funciones y decoradores de orden superior. Solo son válidos
   cuando se utilizan en "Concatenate", o como primer argumento de
   "Callable", o como parámetros para genéricos definidos por el
   usuario. Consulte "Generic" para obtener más información sobre
   tipos genéricos.

   Por ejemplo, para agregar un registro básico a una función, se
   puede crear un decorador "add_logging" para registrar llamadas a
   funciones. La variable de especificación de parámetros le dice al
   verificador de tipo que el invocable pasado al decorador y el nuevo
   invocable retornado por él tienen parámetros de tipo
   interdependientes:

      from collections.abc import Callable
      from typing import TypeVar, ParamSpec
      import logging

      T = TypeVar('T')
      P = ParamSpec('P')

      def add_logging(f: Callable[P, T]) -> Callable[P, T]:
          '''A type-safe decorator to add logging to a function.'''
          def inner(*args: P.args, **kwargs: P.kwargs) -> T:
              logging.info(f'{f.__name__} was called')
              return f(*args, **kwargs)
          return inner

      @add_logging
      def add_two(x: float, y: float) -> float:
          '''Add two numbers together.'''
          return x + y

   Sin "ParamSpec", la forma más sencilla de anotar esto anteriormente
   era usar un "TypeVar" con "Callable[..., Any]" enlazado. Sin
   embargo, esto causa dos problemas:

   1. El verificador de tipo no puede verificar la función "inner"
      porque "*args" y "**kwargs" deben escribirse "Any".

   2. Es posible que se requiera "cast()" en el cuerpo del decorador
      "add_logging" al retornar la función "inner", o se debe indicar
      al verificador de tipo estático que ignore el "return inner".

   args

   kwargs

      Dado que "ParamSpec" captura tanto parámetros posicionales como
      de palabras clave, "P.args" y "P.kwargs" se pueden utilizar para
      dividir un "ParamSpec" en sus componentes. "P.args" representa
      la tupla de parámetros posicionales en una llamada determinada y
      solo debe usarse para anotar "*args". "P.kwargs" representa la
      asignación de parámetros de palabras clave a sus valores en una
      llamada determinada y solo debe usarse para anotar "**kwargs".
      Ambos atributos requieren que el parámetro anotado esté dentro
      del alcance. En tiempo de ejecución, "P.args" y "P.kwargs" son
      instancias respectivamente de "ParamSpecArgs" y
      "ParamSpecKwargs".

   Las variables de especificación de parámetros creadas con
   "covariant=True" o "contravariant=True" se pueden utilizar para
   declarar tipos genéricos covariantes o contravariantes. También se
   acepta el argumento "bound", similar a "TypeVar". Sin embargo, la
   semántica real de estas palabras clave aún no se ha decidido.

   Nuevo en la versión 3.10.

   Nota:

     Solo las variables de especificación de parámetros definidas en
     el ámbito global pueden ser serializadas.

   Ver también:

     * **PEP 612** - Variables de especificación de parámetros (el PEP
       que introdujo "ParamSpec" y "Concatenate").

     * "Callable" y "Concatenate".

typing.ParamSpecArgs

typing.ParamSpecKwargs

   Argumentos y atributos de argumentos de palabras clave de un
   "ParamSpec". El atributo "P.args" de un "ParamSpec" es una
   instancia de "ParamSpecArgs" y "P.kwargs" es una instancia de
   "ParamSpecKwargs". Están pensados para la introspección en tiempo
   de ejecución y no tienen un significado especial para los
   verificadores de tipo estático.

   Llamar a "get_origin()" en cualquiera de estos objetos retornará el
   "ParamSpec" original:

      P = ParamSpec("P")
      get_origin(P.args)  # returns P
      get_origin(P.kwargs)  # returns P

   Nuevo en la versión 3.10.

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

   See **PEP 544** for more details. Protocol classes decorated with
   "runtime_checkable()" (described later) act as simple-minded
   runtime protocols that check only the presence of given attributes,
   ignoring their type signatures.

   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)

      @runtime_checkable
      class Named(Protocol):
          name: str

      import threading
      assert isinstance(threading.Thread(name='Bob'), Named)

   Nota:

     "runtime_checkable()" will check only the presence of the
     required methods or attributes, not their type signatures or
     types. For example, "ssl.SSLObject" is a class, therefore it
     passes an "issubclass()" check against "Callable".  However, the
     "ssl.SSLObject.__init__" method exists only to raise a
     "TypeError" with a more informative message, therefore making it
     impossible to call (instantiate) "ssl.SSLObject".

   Nota:

     An "isinstance()" check against a runtime-checkable protocol can
     be surprisingly slow compared to an "isinstance()" check against
     a non-protocol class. Consider using alternative idioms such as
     "hasattr()" calls for structural checks in performance-sensitive
     code.

   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.

class typing.NewType(name, tp)

   Una clase auxiliar para indicar un tipo diferenciado a un
   comprobador de tipos, consulte NewType. En tiempo de ejecución,
   retorna un objeto que retorna su argumento cuando se llama. Uso:

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

   Nuevo en la versión 3.5.2.

   Distinto en la versión 3.10: "NewType" es ahora una clase en lugar
   de una función.

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:

      Point2D = TypedDict('Point2D', x=int, y=int, label=str)
      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})

   De forma predeterminada, todas las claves deben estar presentes en
   un "TypedDict". Es posible anular esto especificando la totalidad.
   Uso:

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

   Esto significa que un "Point2D" "TypedDict" puede tener cualquiera
   de las claves omitidas. Solo se espera que un verificador de tipo
   admita un "False" literal o "True" como valor del argumento
   "total". "True" es el predeterminado y hace que todos los elementos
   definidos en el cuerpo de la clase sean obligatorios.

   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 dicts (see
   Prácticas recomendadas para las anotaciones for more information on
   annotations best practices), "__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__

      Nuevo en la versión 3.9.

   __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

      Nuevo en la versión 3.9.

   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" now supports
   subscripting ("[]"). See **PEP 585** and 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" now supports
   subscripting ("[]"). See **PEP 585** and 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" now supports
   subscripting ("[]"). See **PEP 585** and 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" now supports
   subscripting ("[]"). See **PEP 585** and 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" now
   supports subscripting ("[]"). See **PEP 585** and 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" now
   supports subscripting ("[]"). See **PEP 585** and 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" now supports
   subscripting ("[]"). See **PEP 585** and 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" now supports
   subscripting ("[]"). See **PEP 585** and 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" now supports
   subscripting ("[]"). See **PEP 585** and Tipo Alias Genérico.


Otros tipos concretos
~~~~~~~~~~~~~~~~~~~~~

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

   El tipo genérico "IO[AnyStr]" y sus subclases "TextIO(IO[str])" y
   "BinaryIO(IO[bytes])" representan los tipos de flujos de E/S como
   los retornados por "open()".

   Obsoleto desde la versión 3.8, se eliminará en la versión 3.13: El
   espacio de nombres "typing.io" está obsoleto y se eliminará. En su
   lugar, estos tipos deben importarse directamente desde "typing".

class typing.Pattern
class typing.Match

   Estos alias de tipo corresponden a los tipos retornados de
   "re.compile()" y "re.match()". Estos tipos (y las funciones
   correspondientes) son genéricos en "AnyStr" y se pueden hacer
   específicos escribiendo "Pattern[str]", "Pattern[bytes]",
   "Match[str]" o "Match[bytes]".

   Obsoleto desde la versión 3.8, se eliminará en la versión 3.13: El
   espacio de nombres "typing.re" está obsoleto y se eliminará. En su
   lugar, estos tipos deben importarse directamente desde "typing".

   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(Collection[T_co])

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

   Obsoleto desde la versión 3.9: "collections.abc.Set" now supports
   subscripting ("[]"). See **PEP 585** and 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" now
   supports subscripting ("[]"). See **PEP 585** and 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" now
   supports subscripting ("[]"). See **PEP 585** and 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" now
   supports subscripting ("[]"). See **PEP 585** and Tipo Alias
   Genérico.

class typing.ItemsView(MappingView, AbstractSet[tuple[KT_co, VT_co]])

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

   Obsoleto desde la versión 3.9: "collections.abc.ItemsView" now
   supports subscripting ("[]"). See **PEP 585** and Tipo Alias
   Genérico.

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

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

   Obsoleto desde la versión 3.9: "collections.abc.KeysView" now
   supports subscripting ("[]"). See **PEP 585** and Tipo Alias
   Genérico.

class typing.Mapping(Collection[KT], Generic[KT, 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" now
   supports subscripting ("[]"). See **PEP 585** and Tipo Alias
   Genérico.

class typing.MappingView(Sized)

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

   Obsoleto desde la versión 3.9: "collections.abc.MappingView" now
   supports subscripting ("[]"). See **PEP 585** and 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" now
   supports subscripting ("[]"). See **PEP 585** and 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"
   now supports subscripting ("[]"). See **PEP 585** and 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" now
   supports subscripting ("[]"). See **PEP 585** and 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" now
   supports subscripting ("[]"). See **PEP 585** and Tipo Alias
   Genérico.

class typing.ValuesView(MappingView, Collection[_VT_co])

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

   Obsoleto desde la versión 3.9: "collections.abc.ValuesView" now
   supports subscripting ("[]"). See **PEP 585** and 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" now
   supports subscripting ("[]"). See **PEP 585** and 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" now
   supports subscripting ("[]"). See **PEP 585** and 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" now
   supports subscripting ("[]"). See **PEP 585** and 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" now
   supports subscripting ("[]"). See **PEP 585** and 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" now
   supports subscripting ("[]"). See **PEP 585** and 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.AsyncGenerator" now
   supports subscripting ("[]"). See **PEP 585** and 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" now
   supports subscripting ("[]"). See **PEP 585** and 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" now
   supports subscripting ("[]"). See **PEP 585** and 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" now
   supports subscripting ("[]"). See **PEP 585** and 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"
   now supports subscripting ("[]"). See **PEP 585** and 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" now supports subscripting
   ("[]"). See **PEP 585** and 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>

   See **PEP 484** for more details and comparison with other typing
   semantics.

@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']
      }

   Nota:

     "get_type_hints()" no funciona con alias de tipo importados que
     incluyen referencias hacia adelante. Habilitar la evaluación
     pospuesta de anotaciones (**PEP 563**) puede eliminar la
     necesidad de la mayoría de las referencias futuras.

   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 escritura de la forma "X[Y, Z, ...]", estas
   funciones retornan "X" y "(Y, Z, ...)". Si "X" es un alias genérico
   para una clase incorporada o "collections", se normaliza a la clase
   original. Si "X" es una unión o "Literal" contenido en otro tipo
   genérico, el orden de "(Y, Z, ...)" puede ser diferente del orden
   de los argumentos originales "[Y, Z, ...]" debido al tipo de
   almacenamiento en caché. Para objetos no admitidos, retorna "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.

typing.is_typeddict(tp)

   Compruebe si un tipo es "TypedDict".

   Por ejemplo:

      class Film(TypedDict):
          title: str
          year: int

      is_typeddict(Film)  # => True
      is_typeddict(list | str)  # => False

   Nuevo en la versión 3.10.

class typing.ForwardRef

   Una clase utilizada para la representación de escritura interna de
   referencias de cadena hacia adelante. Por ejemplo,
   "List["SomeClass"]" se transforma implícitamente en
   "List[ForwardRef("SomeClass")]". Esta clase no debe ser instanciada
   por un usuario, pero puede ser utilizada por herramientas de
   introspección.

   Nota:

     Los tipos genéricos de **PEP 585**, como "list["SomeClass"]", no
     se transformarán implícitamente en
     "list[ForwardRef("SomeClass")]" y, por lo tanto, no se resolverán
     automáticamente en "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.
