"typing" --- Soporte para *type hints*
**************************************

Added in version 3.5.

**Source code:** Lib/typing.py

Nota:

  The Python runtime does not enforce function and variable type
  annotations. They can be used by third party tools such as *type
  checkers*, IDEs, linters, etc.

======================================================================

This module provides runtime support for type hints.

Consider the function below:

   def surface_area_of_cube(edge_length: float) -> str:
       return f"The surface area of the cube is {6 * edge_length ** 2}."

The function "surface_area_of_cube" takes an argument expected to be
an instance of "float", as indicated by the *type hint* "edge_length:
float". The function is expected to return an instance of "str", as
indicated by the "-> str" hint.

While type hints can be simple classes like "float" or "str", they can
also be more complex. The "typing" module provides a vocabulary of
more advanced type hints.

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:

  ”Guía rápida sobre los indicadores de tipo”
     Una visión general de los indicadores de tipo (hospedado por mypy
     docs, en inglés.)

  Sección “Referencia sobre sistema de tipo” de the mypy docs
     El sistema de tipos de Python es estandarizado por medio de las
     PEPs, así que esta referencia debe aplicarse a la mayoría de
     validadores de tipo de Python. (Algunas partes pueden referirse
     específicamente a mypy.)

  "Static Typing with Python"
     Documentación independiente del validador de tipos escrita por la
     comunidad que detalla las características del sistema de tipos,
     herramientas útiles relacionadas con el tipado y mejores
     prácticas.


Specification for the Python Type System
========================================

The canonical, up-to-date specification of the Python type system can
be found at "Specification for the Python type system".


Alias de tipo
=============

Un alias de tipo se define usando la declaración "type", el cual crea
una instancia de "TypeAliasType". En este ejemplo, "Vector" y
"list[float]" serán tratados de manera equivalente a los validadores
de tipo estático:

   type 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 firmas de tipo
complejas. Por ejemplo:

   from collections.abc import Sequence

   type ConnectionOptions = dict[str, str]
   type Address = tuple[str, int]
   type 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:
       ...

La declaración "type" es nueva en Python 3.12. Para compatibilidad con
versiones anteriores, los alias de tipo también se pueden crear
mediante una asignación simple.:

   Vector = list[float]

O marcarse con "TypeAlias" para dejar explícito que se trata de un
alias de tipo, no de una asignación de variable normal:

   from typing import TypeAlias

   Vector: TypeAlias = list[float]


NewType
=======

Use la clase auxiliar "NewType" para crear tipos distintos:

   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)

Tenga en cuenta que estas validaciones solo las aplica el validador de
tipo estático. En tiempo de ejecución, la declaración "Derived =
NewType('Derived', Base)" hará que "Derived" sea una clase que retorna
inmediatamente cualquier parámetro que le pase. Eso significa que la
expresión "Derived(some_value)" no crea una nueva clase ni introduce
mucha sobrecarga más allá de la de una llamada de función regular.

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:

  Recuerde que el uso de alias de tipo implica que los dos tipos son
  *equivalentes* entre sí. Haciendo "type 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.

Added in version 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.

Distinto en la versión 3.11: El rendimiento al llamar "NewType" ha
sido restaurado a su nivel en Python 3.9.


Anotaciones en objetos invocables
=================================

Functions -- or other *callable* objects -- can be annotated using
"collections.abc.Callable" or deprecated "typing.Callable".
"Callable[[int], str]" signifies a function that takes a single
parameter of type "int" and returns a "str".

Por ejemplo:

   from collections.abc import Callable, Awaitable

   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

La sintaxis de suscripción siempre debe utilizarse con exactamente dos
valores: una lista de argumentos y el tipo de retorno. La lista de
argumentos debe ser una lista de tipos, un "ParamSpec", "Concatenate"
o una elipsis. El tipo de retorno debe ser un único tipo.

Si se proporciona una elipsis como lista de argumentos, indica que
sería aceptable un invocable con cualquier lista de parámetros
arbitraria:

   def concat(x: str, y: str) -> str:
       return x + y

   x: Callable[..., str]
   x = str     # OK
   x = concat  # Also OK

"Callable" cannot express complex signatures such as functions that
take a variadic number of arguments, overloaded functions, or
functions that have keyword-only parameters. However, these signatures
can be expressed by defining a "Protocol" class with a "__call__()"
method:

   from collections.abc import Iterable
   from typing import Protocol

   class Combiner(Protocol):
       def __call__(self, *vals: bytes, maxlen: int | None = None) -> list[bytes]: ...

   def batch_proc(data: Iterable[bytes], cb_results: Combiner) -> bytes:
       for item in data:
           ...

   def good_cb(*vals: bytes, maxlen: int | None = None) -> list[bytes]:
       ...
   def bad_cb(*vals: bytes, maxitems: int | None) -> list[bytes]:
       ...

   batch_proc([], good_cb)  # OK
   batch_proc([], bad_cb)   # Error! Argument 2 has incompatible type because of
                            # different name and kind in the callback

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" ahora es compatible con
"ParamSpec" y "Concatenate". Consulte **PEP 612** para obtener más
información.

Ver también:

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


Genéricos
=========

Dado que la información de tipo sobre los objetos guardados en
contenedores no se puede inferir estáticamente de manera genérica,
muchas clases de contenedor en la biblioteca estándar admiten
suscripción para indicar los tipos esperados de elementos de
contenedor.

   from collections.abc import Mapping, Sequence

   class Employee: ...

   # Sequence[Employee] indicates that all elements in the sequence
   # must be instances of "Employee".
   # Mapping[str, str] indicates that all keys and all values in the mapping
   # must be strings.
   def notify_by_email(employees: Sequence[Employee],
                       overrides: Mapping[str, str]) -> None: ...

Funciones y clases genéricas pueden ser parametrizadas usando type
parameter syntax:

   from collections.abc import Sequence

   def first[T](l: Sequence[T]) -> T:  # Function is generic over the TypeVar "T"
       return l[0]

O utilizando directamente la fábrica "TypeVar":

   from collections.abc import Sequence
   from typing import TypeVar

   U = TypeVar('U')                  # Declare type variable "U"

   def second(l: Sequence[U]) -> U:  # Function is generic over the TypeVar "U"
       return l[1]

Distinto en la versión 3.12: El soporte sintáctico para genéricos es
nuevo en Python 3.12.


Anotaciones en tuplas
=====================

En la mayoría de los contenedores de Python, el sistema de tipado
supone que todos los elementos del contenedor serán del mismo tipo.
Por ejemplo:

   from collections.abc import Mapping

   # Type checker will infer that all elements in ``x`` are meant to be ints
   x: list[int] = []

   # Type checker error: ``list`` only accepts a single type argument:
   y: list[int, str] = [1, 'foo']

   # Type checker will infer that all keys in ``z`` are meant to be strings,
   # and that all values in ``z`` are meant to be either strings or ints
   z: Mapping[str, str | int] = {}

"list" solo acepta un argumento de tipo, por lo que un validador de
tipos emitiría un error en la asignación "y" anterior. De manera
similar, "Mapping" solo acepta dos argumentos de tipo: el primero
indica el tipo de las claves y el segundo indica el tipo de los
valores.

Sin embargo, a diferencia de la mayoría de los demás contenedores de
Python, es común en el código idiomático de Python que las tuplas
tengan elementos que no sean todos del mismo tipo. Por este motivo,
las tuplas son un caso especial en el sistema de tipado de Python.
"tuple" acepta *cualquier número* de argumentos de tipo:

   # OK: ``x`` is assigned to a tuple of length 1 where the sole element is an int
   x: tuple[int] = (5,)

   # OK: ``y`` is assigned to a tuple of length 2;
   # element 1 is an int, element 2 is a str
   y: tuple[int, str] = (5, "foo")

   # Error: the type annotation indicates a tuple of length 1,
   # but ``z`` has been assigned to a tuple of length 3
   z: tuple[int] = (1, 2, 3)

Para indicar una tupla que podría tener *cualquier* tamaño y en la que
todos los elementos son del mismo tipo "T", utilice "tuple[T, ...]".
Para indicar una tupla vacía, utilice "tuple[()]". El uso de "tuple"
simple como anotación es equivalente a utilizar "tuple[Any, ...]":

   x: tuple[int, ...] = (1, 2)
   # These reassignments are OK: ``tuple[int, ...]`` indicates x can be of any length
   x = (1, 2, 3)
   x = ()
   # This reassignment is an error: all elements in ``x`` must be ints
   x = ("foo", "bar")

   # ``y`` can only ever be assigned to an empty tuple
   y: tuple[()] = ()

   z: tuple = ("foo", "bar")
   # These reassignments are OK: plain ``tuple`` is equivalent to ``tuple[Any, ...]``
   z = (1, 2, 3)
   z = ()


El tipo de objetos de clase
===========================

A variable annotated with "C" may accept a value of type "C". In
contrast, a variable annotated with "type[C]" (or deprecated
"typing.Type[C]") may accept values that are classes themselves --
specifically, it will accept the *class object* of "C". For example:

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

Tenga en cuenta que "type[C]" es covariante:

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

   def make_new_user(user_class: type[User]) -> User:
       # ...
       return user_class()

   make_new_user(User)      # OK
   make_new_user(ProUser)   # Also OK: ``type[ProUser]`` is a subtype of ``type[User]``
   make_new_user(TeamUser)  # Still fine
   make_new_user(User())    # Error: expected ``type[User]`` but got ``User``
   make_new_user(int)       # Error: ``type[int]`` is not a subtype of ``type[User]``

Los únicos parámetros legales para "type" son las clases, "Any",
variables de tipo y uniones de cualquiera de estos tipos. Por ejemplo:

   def new_non_team_user(user_class: type[BasicUser | ProUser]): ...

   new_non_team_user(BasicUser)  # OK
   new_non_team_user(ProUser)    # OK
   new_non_team_user(TeamUser)   # Error: ``type[TeamUser]`` is not a subtype
                                 # of ``type[BasicUser | ProUser]``
   new_non_team_user(User)       # Also an error

"type[Any]" es equivalente a "type", que es la raíz de la jerarquía de
metaclases de Python.


Annotating generators and coroutines
====================================

A generator can be annotated using the generic type
"Generator[YieldType, SendType, ReturnType]". For example:

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

Note that unlike many other generic classes in the standard library,
the "SendType" of "Generator" behaves contravariantly, not covariantly
or invariantly.

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

Async generators are handled in a similar fashion, but don't expect a
"ReturnType" type argument ("AsyncGenerator[YieldType, SendType]"):

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

As in the synchronous case, "AsyncIterable[YieldType]" and
"AsyncIterator[YieldType]" are available as well:

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

Coroutines can be annotated using "Coroutine[YieldType, SendType,
ReturnType]". Generic arguments correspond to those of "Generator",
for example:

   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


Tipos genéricos definidos por el usuario
========================================

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

   from logging import Logger

   class LoggedVar[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)

This syntax indicates that the class "LoggedVar" is parameterised
around a single type variable "T" . This also makes "T" valid as a
type within the class body.

Las clases genéricas heredan implícitamente de "Generic". Para
compatibilidad con Python 3.11 y versiones anteriores, también es
posible heredar explícitamente de "Generic" para indicar una clase
genérica:

   from typing import TypeVar, Generic

   T = TypeVar('T')

   class LoggedVar(Generic[T]):
       ...

Las clases genéricas tienen métodos "__class_getitem__()", lo que
significa que se pueden parametrizar en tiempo de ejecución (por
ejemplo, "LoggedVar[int]" a continuación):

   from collections.abc import Iterable

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

Un tipo genérico puede tener un numero cualquiera de variables de
tipo. Se permiten todas las variaciones de "TypeVar" para ser usadas
como parámetros de un tipo genérico:

   from typing import TypeVar, Generic, Sequence

   class WeirdTrio[T, B: Sequence[bytes], S: (int, str)]:
       ...

   OldT = TypeVar('OldT', contravariant=True)
   OldB = TypeVar('OldB', bound=Sequence[bytes], covariant=True)
   OldS = TypeVar('OldS', int, str)

   class OldWeirdTrio(Generic[OldT, OldB, OldS]):
       ...

Cada argumento de variable de tipo de "Generic" debe ser distinto. Por
lo tanto, esto no es válido:

   from typing import TypeVar, Generic
   ...

   class Pair[M, M]:  # SyntaxError
       ...

   T = TypeVar('T')

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

Las clases genéricas también pueden heredar de otras clases:

   from collections.abc import Sized

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

Al heredar de clases genéricas, algunos parámetros de tipo podrían ser
fijos:

   from collections.abc import Mapping

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

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

El uso de una clase genérica sin especificar parámetros de tipo supone
"Any" para cada posición. En el siguiente ejemplo, "MyIterable" no es
genérico, sino que hereda implícitamente de "Iterable[Any]":

   from collections.abc import Iterable

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

También se admiten alias de tipos genéricos definidos por el usuario.
Ejemplos:

   from collections.abc import Iterable

   type Response[S] = Iterable[S] | int

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

   type Vec[T] = Iterable[tuple[T, T]]

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

Para compatibilidad con versiones anteriores, también se pueden crear
alias de tipos genéricos mediante una asignación simple:

   from collections.abc import Iterable
   from typing import TypeVar

   S = TypeVar("S")
   Response = Iterable[S] | int

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

Distinto en la versión 3.12: La compatibilidad sintáctica con
genéricos y alias de tipo es una novedad en la versión 3.12. Antes,
las clases genéricas debían heredar explícitamente de "Generic" o
contener una variable de tipo en una de sus bases.

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 en el formato "[**P]". El comportamiento es coherente con
las variables de tipo descritas anteriormente, ya que el módulo de
tipado 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 utilizar una lista de tipos para sustituir un "ParamSpec":

   >>> class Z[T, **P]: ...  # T is a TypeVar; P is a ParamSpec
   ...
   >>> Z[int, [dict, float]]
   __main__.Z[int, [dict, float]]

También se pueden crear clases genéricas sobre "ParamSpec" utilizando
herencia explícita de "Generic". En este caso, no se utiliza "**":

   from typing import ParamSpec, Generic

   P = ParamSpec('P')

   class Z(Generic[P]):
       ...

Otra diferencia entre "TypeVar" y "ParamSpec" es que una variable
genérica con una sola especificación de parámetros aceptará listas de
parámetros en los formatos "X[[Type1, Type2, ...]]" y también
"X[Type1, Type2, ...]" por razones estéticas. Internamente, el último
se convierte al primero, por lo que los siguientes son equivalentes:

   >>> class X[**P]: ...
   ...
   >>> X[int, str]
   __main__.X[[int, str]]
   >>> X[[int, str]]
   __main__.X[[int, str]]

Tenga en cuenta que los genéricos con "ParamSpec" pueden no tener
"__parameters__" correctos 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.

Una clase genérica definida por el usuario puede tener clases ABC sin
que se produzca un conflicto de metaclases. No se admiten metaclases
genéricas. El resultado de parametrizar los genéricos se almacena en
caché y la mayoría de los tipos en el módulo de tipificación son
*hashable* y comparables en términos de igualdad.


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

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 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
================================

Inicialmente, el **PEP 484** definió el uso de *subtipado nominal*
para el sistema de tipado estático de Python. Esto implica que una
clase "A" será permitida allí donde se espere una clase "B" si y solo
si "A" es una subclase de "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 esta 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 "typing" define las siguientes clases, funciones y
decoradores.


Primitivos especiales de tipado
-------------------------------


Tipos especiales
~~~~~~~~~~~~~~~~

Estos pueden ser usados como tipos en anotaciones. No soportan
suscripción usando "[]".

typing.Any

   Tipo especial que indica un tipo sin restricciones.

   * Todos los tipos son compatibles con "Any".

   * "Any" es compatible con todos los tipos.

   Distinto en la versión 3.11: Ahora es posible utilizar "Any" como
   una clase base. Esto puede ser útil para evitar errores del
   validador de tipos con clases que pueden hacer uso del *duck
   typing* en cualquier punto, o que sean altamente dinámicas.

typing.AnyStr

   Una variables de tipo restringida.

   Definición:

      AnyStr = TypeVar('AnyStr', str, bytes)

   "AnyStr" está pensado para ser utilizado por funciones que pueden
   aceptar argumentos "str" o "bytes" pero que no puedan permitir que
   los dos se mezclen.

   Por ejemplo:

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

      concat("foo", "bar")    # OK, output has type 'str'
      concat(b"foo", b"bar")  # OK, output has type 'bytes'
      concat("foo", b"bar")   # Error, cannot mix str and bytes

   Tenga en cuenta que, a pesar de su nombre, "AnyStr" no tiene nada
   que ver con el tipo "Any", ni significa “cualquier cadena de
   caracteres”. En particular, "AnyStr" y "str | bytes" son diferentes
   entre sí y tienen diferentes casos de uso:

      # Invalid use of AnyStr:
      # The type variable is used only once in the function signature,
      # so cannot be "solved" by the type checker
      def greet_bad(cond: bool) -> AnyStr:
          return "hi there!" if cond else b"greetings!"

      # The better way of annotating this function:
      def greet_proper(cond: bool) -> str | bytes:
          return "hi there!" if cond else b"greetings!"

typing.LiteralString

   Tipo especial que incluye sólo cadenas de caracteres literales.

   Cualquier cadena de caracteres literal es compatible con
   "LiteralString", al igual que cualquier otro "LiteralString". Sin
   embargo, un objeto cuyo tipo sea simplemente "str" no lo es. Una
   cadena de caracteres creada mediante la composición de objetos cuyo
   tipo sea "LiteralString" también es aceptable como "LiteralString".

   Por ejemplo:

      def run_query(sql: LiteralString) -> None:
          ...

      def caller(arbitrary_string: str, literal_string: LiteralString) -> None:
          run_query("SELECT * FROM students")  # OK
          run_query(literal_string)  # OK
          run_query("SELECT * FROM " + literal_string)  # OK
          run_query(arbitrary_string)  # type checker error
          run_query(  # type checker error
              f"SELECT * FROM students WHERE name = {arbitrary_string}"
          )

   "LiteralString" es útil para API sensibles en las que cadenas de
   caracteres arbitrarias generadas por el usuario podrían generar
   problemas. Por ejemplo, los dos casos anteriores que generan
   errores de verificación de tipos podrían ser vulnerables a un
   ataque de inyección SQL.

   Véase **PEP 675** para más detalle.

   Added in version 3.11.

typing.Never
typing.NoReturn

   "Never" and "NoReturn" represent the bottom type, a type that has
   no members.

   They can be used to indicate that a function never returns, such as
   "sys.exit()":

      from typing import Never  # or NoReturn

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

   Or to define a function that should never be called, as there are
   no valid arguments, such as "assert_never()":

      from typing import Never  # or NoReturn

      def never_call_me(arg: Never) -> None:
          pass

      def int_or_str(arg: int | str) -> None:
          never_call_me(arg)  # type checker error
          match arg:
              case int():
                  print("It's an int")
              case str():
                  print("It's a str")
              case _:
                  never_call_me(arg)  # OK, arg is of type Never (or NoReturn)

   "Never" and "NoReturn" have the same meaning in the type system and
   static type checkers treat both equivalently.

   Added in version 3.6.2: Added "NoReturn".

   Added in version 3.11: Added "Never".

typing.Self

   Tipo especial que representa la clase capturada actual.

   Por ejemplo:

      from typing import Self, reveal_type

      class Foo:
          def return_self(self) -> Self:
              ...
              return self

      class SubclassOfFoo(Foo): pass

      reveal_type(Foo().return_self())  # Revealed type is "Foo"
      reveal_type(SubclassOfFoo().return_self())  # Revealed type is "SubclassOfFoo"

   Esta anotación es semánticamente equivalente a lo siguiente, aunque
   de una manera más sucinta:

      from typing import TypeVar

      Self = TypeVar("Self", bound="Foo")

      class Foo:
          def return_self(self: Self) -> Self:
              ...
              return self

   En general, si algo devuelve "self", como en los ejemplos
   anteriores, se debe utilizar "Self" en la  anotación del retorno.
   Si "Foo.return_self" se anotó como que devuelve "”Foo”", entonces
   el validador de tipos inferiría que el objeto devuelto desde
   "SubclassOfFoo.return_self" es del tipo "Foo" en lugar de
   "SubclassOfFoo".

   Otros casos de uso comunes incluyen:

   * "classmethod" usados como constructores alternativos y retornan
     instancias del parámetro "cls".

   * Anotar un método "__enter__()" que retorna self.

   No debe utilizar "Self" como anotación de retorno si no se
   garantiza que el método devuelva una instancia de una subclase
   cuando la clase sea heredada:

      class Eggs:
          # Self would be an incorrect return annotation here,
          # as the object returned is always an instance of Eggs,
          # even in subclasses
          def returns_eggs(self) -> "Eggs":
              return Eggs()

   Véase **PEP 673** para más detalle.

   Added in version 3.11.

typing.TypeAlias

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

   Por ejemplo:

      from typing import TypeAlias

      Factors: TypeAlias = list[int]

   "TypeAlias" es particularmente útil en versiones anteriores de
   Python para anotar alias que utilizan referencias para versiones
   posteriores, ya que puede ser difícil para los validadores de tipos
   distinguirlos de las asignaciones de variables normales:

      from typing import Generic, TypeAlias, TypeVar

      T = TypeVar("T")

      # "Box" does not exist yet,
      # so we have to use quotes for the forward reference on Python <3.12.
      # Using ``TypeAlias`` tells the type checker that this is a type alias declaration,
      # not a variable assignment to a string.
      BoxOfStrings: TypeAlias = "Box[str]"

      class Box(Generic[T]):
          @classmethod
          def make_box_of_strings(cls) -> BoxOfStrings: ...

   Ver **PEP 613** para más detalle.

   Added in version 3.10.

   Obsoleto desde la versión 3.12: "TypeAlias" ha sido descontinuado
   en favor de la declaración "type", la cual crea instancias de
   "TypeAliasType" y que admite de forma nativa referencias de
   versiones posteriores de Python. Tenga en cuenta que, si bien
   "TypeAlias" y "TypeAliasType" tienen propósitos similares y tienen
   nombres similares, son distintos y el último no es el tipo del
   primero. La eliminación de "TypeAlias" no está prevista
   actualmente, pero se recomienda a los usuarios que migren a las
   declaraciones "type".


Formas especiales
~~~~~~~~~~~~~~~~~

Estos se pueden utilizar como tipos en anotaciones. Todos admiten la
suscripción mediante "[]", pero cada uno tiene una sintaxis única.

typing.Union

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

   Para definir una unión, use p. ej. "Union[int, str]" o la
   abreviatura "int | str". Se recomienda el uso de la abreviatura.
   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] == int | str

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

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

   * No es posible 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

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

   Forma especial para anotar funciones de orden superior.

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

   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

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

      def with_lock[**P, R](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])

   Added in version 3.10.

   Ver también:

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

     * "ParamSpec"

     * Anotaciones en objetos invocables

typing.Literal

   Tipo especial que solo incluye cadenas literales.

   "Literal" se puede utilizar para indicar a los validadores de tipos
   que el objeto anotado tiene un valor equivalente a uno de los
   literales proporcionados.

   Por ejemplo:

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

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

   Added in version 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

   Added in version 3.5.3.

typing.Final

   Construcción de tipado especial para indicar nombres finales a los
   validadores de tipos.

   Los nombres finales no se pueden reasignar en ningún ámbito. Los
   nombres finales declarados en ámbitos de clase no se pueden anular
   en subclases.

   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.

   Added in version 3.8.

typing.Required

   Construcción de tipado especial para marcar una clave "TypedDict"
   como requerida.

   Esto es útil principalmente para TypedDicts "total=False". Vea
   "TypedDict" y **PEP 655** para obtener más detalles.

   Added in version 3.11.

typing.NotRequired

   Construcción de tipado especial para marcar una clave "TypedDict"
   como potencialmente faltante.

   Véase "TypedDict" y **PEP 655** para más detalle.

   Added in version 3.11.

typing.Annotated

   Forma de escritura especial para agregar metadatos específicos del
   contexto a una anotación.

   Agregue metadatos "x" a un tipo "T" determinado mediante la
   anotación "Annotated[T, x]". Los metadatos agregados mediante
   "Annotated" pueden usarse con herramientas de análisis estático o
   en tiempo de ejecución. En tiempo de ejecución, los metadatos se
   almacenan en un atributo "__metadata__".

   Si una biblioteca o herramienta encuentra una anotación
   "Annotated[T, x]" y no tiene una lógica especial para los
   metadatos, debe ignorar los metadatos y simplemente tratar la
   anotación como "T". Como tal, "Annotated" puede ser útil para el
   código que desea usar anotaciones para fines fuera del sistema de
   tipado estático de Python.

   El uso de "Annotated[T, x]" como anotación aún permite la
   verificación de tipos estática de "T", ya que los validadores de
   tipos simplemente ignorarán los metadatos "x". De esta manera,
   "Annotated" difiere del decorador "@no_type_check", que también se
   puede usar para agregar anotaciones fuera del alcance del sistema
   de tipado, pero deshabilita por completo la verificación de tipos
   para una función o clase.

   The responsibility of how to interpret the metadata lies with the
   tool or library encountering an "Annotated" annotation. A tool or
   library encountering an "Annotated" type can scan through the
   metadata elements to determine if they are of interest (e.g., using
   "isinstance()").

   Annotated[<type>, <metadata>]

   A continuación se muestra un ejemplo de cómo podría utilizar
   "Annotated" para agregar metadatos a las anotaciones de tipo si
   estuviera realizando un análisis de rango:

      @dataclass
      class ValueRange:
          lo: int
          hi: int

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

   The first argument to "Annotated" must be a valid type. Multiple
   metadata elements can be supplied as "Annotated" supports variadic
   arguments. The order of the metadata elements is preserved and
   matters for equality checks:

      @dataclass
      class ctype:
           kind: str

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

      assert a1 != a2  # Order matters

   Depende de la herramienta que consume las anotaciones decidir si el
   cliente puede agregar varios elementos de metadatos a una anotación
   y cómo fusionar esas anotaciones.

   Los tipos anidados "Annotated" se aplanan. El orden de los
   elementos de metadatos comienza con la anotación más interna:

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

   Los elementos de metadatos duplicados no se eliminan:

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

   "Annotated" se puede utilizar con alias anidados y genéricos:

         @dataclass
         class MaxLen:
             value: int

         type Vec[T] = Annotated[list[tuple[T, T]], MaxLen(10)]

         # When used in a type annotation, a type checker will treat "V" the same as
         # ``Annotated[list[tuple[int, int]], MaxLen(10)]``:
         type V = Vec[int]

   No se puede utilizar "Annotated" con un "TypeVarTuple"
   descomprimido:

      type Variadic[*Ts] = Annotated[*Ts, Ann1] = Annotated[T1, T2, T3, ..., Ann1]  # NOT valid

   where "T1", "T2", ... are "TypeVars". This is invalid as only one
   type should be passed to Annotated.

   De forma predeterminada, "get_type_hints()" elimina los metadatos
   de las anotaciones. Pase "include_extras=True" para conservar los
   metadatos:

         >>> from typing import Annotated, get_type_hints
         >>> def func(x: Annotated[int, "metadata"]) -> None: pass
         ...
         >>> get_type_hints(func)
         {'x': <class 'int'>, 'return': <class 'NoneType'>}
         >>> get_type_hints(func, include_extras=True)
         {'x': typing.Annotated[int, 'metadata'], 'return': <class 'NoneType'>}

   En tiempo de ejecución, los metadatos asociados con un tipo
   "Annotated" se pueden recuperar a través del atributo
   "__metadata__":

         >>> from typing import Annotated
         >>> X = Annotated[int, "very", "important", "metadata"]
         >>> X
         typing.Annotated[int, 'very', 'important', 'metadata']
         >>> X.__metadata__
         ('very', 'important', 'metadata')

   If you want to retrieve the original type wrapped by "Annotated",
   use the "__origin__" attribute:

         >>> from typing import Annotated, get_origin
         >>> Password = Annotated[str, "secret"]
         >>> Password.__origin__
         <class 'str'>

   Note that using "get_origin()" will return "Annotated" itself:

         >>> get_origin(Password)
         <class 'typing.Annotated'>

   Ver también:

     **PEP 593** - Anotaciones flexibles de funciones y variables
        El PEP introduce "Annotated" en la biblioteca estándar.

   Added in version 3.9.

typing.TypeGuard

   Construcción de tipado especial para marcar funciones de protección
   de tipo definidas por el usuario.

   "TypeGuard" se puede utilizar para anotar el tipo de retorno de una
   función de protección de tipo definida por el usuario. "TypeGuard"
   solo acepta un único argumento de tipo. En tiempo de ejecución, las
   funciones marcadas de esta manera deben devolver un valor booleano.

   "TypeGuard" tiene como objetivo beneficiar a *type narrowing*, una
   técnica utilizada por los validadores 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
   validadores de tipo estático sobre esta intención.

   El uso de "-> TypeGuard" le dice al validador 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!")

   If "is_str_list" is a class or instance method, then the type in
   "TypeGuard" maps to the type of the second parameter (after "cls"
   or "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 seguras se deja al usuario.

   "TypeGuard" también funciona con variables de tipo. Véase **PEP
   647** para más detalles.

   Added in version 3.10.

typing.Unpack

   Tipado para marcar conceptualmente un objeto como si hubiera sido
   desempaquetado.

   For example, using the unpack operator "*" on a type variable tuple
   is equivalent to using "Unpack" to mark the type variable tuple as
   having been unpacked:

      Ts = TypeVarTuple('Ts')
      tup: tuple[*Ts]
      # Effectively does:
      tup: tuple[Unpack[Ts]]

   De hecho, "Unpack" se puede usar indistintamente con "*" en el
   contexto de los tipos "typing.TypeVarTuple" y "builtins.tuple". Es
   posible que veas que "Unpack" se usa explícitamente en versiones
   anteriores de Python, donde "*" no se podía usar en ciertos
   lugares:

      # In older versions of Python, TypeVarTuple and Unpack
      # are located in the `typing_extensions` backports package.
      from typing_extensions import TypeVarTuple, Unpack

      Ts = TypeVarTuple('Ts')
      tup: tuple[*Ts]         # Syntax error on Python <= 3.10!
      tup: tuple[Unpack[Ts]]  # Semantically equivalent, and backwards-compatible

   "Unpack" también se puede usar junto con "typing.TypedDict" para
   tipear "**kwargs" en una firma de función:

      from typing import TypedDict, Unpack

      class Movie(TypedDict):
          name: str
          year: int

      # This function expects two keyword arguments - `name` of type `str`
      # and `year` of type `int`.
      def foo(**kwargs: Unpack[Movie]): ...

   Consulte **PEP 692** para obtener más información sobre el uso de
   "Unpack" para tipear "**kwargs".

   Added in version 3.11.


Creación de tipos genéricos y alias de tipos
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Las siguientes clases no se deben utilizar directamente como
anotaciones. Su finalidad es servir de bloques de construcción para
crear tipos genéricos y alias de tipos.

Estos objetos se pueden crear mediante una sintaxis especial (type
parameter lists y la declaración "type"). Para compatibilidad con
Python 3.11 y versiones anteriores, también se pueden crear sin la
sintaxis dedicada, como se documenta a continuación.

class typing.Generic

   Clase base abstracta para tipos genéricos.

   Un tipo genérico normalmente se declara agregando una lista de
   parámetros de tipo después del nombre de la clase:

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

   Esta clase hereda implícitamente de "Generic". La semántica de
   tiempo de ejecución de esta sintaxis se analiza en la Referencia
   del lenguaje.

   Entonces, esta clase se puede usar como sigue:

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

   Aquí los corchetes después del nombre de la función indican una
   función genérica.

   Para compatibilidad con versiones anteriores, las clases genéricas
   también se pueden declarar heredando explícitamente de "Generic".
   En este caso, los parámetros de tipo se deben declarar por
   separado:

      KT = TypeVar('KT')
      VT = TypeVar('VT')

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

class typing.TypeVar(name, *constraints, bound=None, covariant=False, contravariant=False, infer_variance=False)

   Variable de tipo.

   La forma preferida de construir una variable de tipo es a través de
   la sintaxis dedicada para funciones genéricas, clases genéricas y
   alias de tipo genérico:

      class Sequence[T]:  # T is a TypeVar
          ...

   This syntax can also be used to create bounded and constrained type
   variables:

      class StrSequence[S: str]:  # S is a TypeVar with a `str` upper bound;
          ...                     # we can say that S is "bounded by `str`"


      class StrOrBytesSequence[A: (str, bytes)]:  # A is a TypeVar constrained to str or bytes
          ...

   Sin embargo, si se desea, también se pueden construir manualmente
   variables de tipo reutilizables, de la siguiente manera:

      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 existen principalmente para el beneficio de
   los validadores de tipos estáticos. Sirven como parámetros para
   tipos genéricos, así como para definiciones de alias de tipo y
   funciones genéricas. Consulte "Generic" para obtener más
   información sobre tipos genéricos. Las funciones genéricas
   funcionan de la siguiente manera:

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


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


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

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

   La varianza de las variables de tipo es inferida por los
   validadores de tipo cuando se crean a través de la sintáxis de
   parámetros de tipo o cuando se pasa "infer_variance=True". Las
   variables de tipo creadas manualmente se pueden marcar
   explícitamente como covariantes o contravariantes al pasar
   "covariant=True" o "contravariant=True". De manera predeterminada,
   las variables de tipo creadas manualmente son invariantes. Consulte
   **PEP 484** y **PEP 695** para obtener más detalles.

   Bounded type variables and constrained type variables have
   different semantics in several important ways. Using a *bounded*
   type variable means that the "TypeVar" will be solved using the
   most specific type possible:

      x = print_capitalized('a string')
      reveal_type(x)  # revealed type is str

      class StringSubclass(str):
          pass

      y = print_capitalized(StringSubclass('another string'))
      reveal_type(y)  # revealed type is StringSubclass

      z = print_capitalized(45)  # error: int is not a subtype of str

   The upper bound of a type variable can be a concrete type, abstract
   type (ABC or Protocol), or even a union of types:

      # Can be anything with an __abs__ method
      def print_abs[T: SupportsAbs](arg: T) -> None:
          print("Absolute value:", abs(arg))

      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

   Sin embargo, usar una variable de tipo *constrained* significa que
   la "TypeVar" sólo podrá ser determinada como exactamente una de las
   restricciones dadas:

      a = concatenate('one', 'two')
      reveal_type(a)  # revealed type is str

      b = concatenate(StringSubclass('one'), StringSubclass('two'))
      reveal_type(b)  # revealed type 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

   En tiempo de ejecución, "isinstance(x, T)" lanzará "TypeError".

   __name__

      El nombre de la variable de tipo.

   __covariant__

      Si la variable de tipo ha sido marcado explícitamente como
      covariante.

   __contravariant__

      Si la variable de tipo ha sido marcado explícitamente como
      covariante.

   __infer_variance__

      Si los validadores de tipo deben inferir la variación de la
      variable de tipo.

      Added in version 3.12.

   __bound__

      The upper bound of the type variable, if any.

      Distinto en la versión 3.12: Para las variables de tipo creadas
      a través de sintáxis de parámetros de tipo, el límite se evalúa
      solo cuando se accede al atributo, no cuando se crea la variable
      de tipo (consulte Evaluación perezosa).

   __constraints__

      Una tupla que contiene las restricciones de la variable de tipo,
      si las hay.

      Distinto en la versión 3.12: Para las variables de tipo creadas
      a través de la sintáxis de parámetros de tipo, las restricciones
      se evalúan solo cuando se accede al atributo, no cuando se crea
      la variable de tipo (consulte Evaluación perezosa).

   Distinto en la versión 3.12: Ahora es posible declarar variables de
   tipo utilizando la sintaxis de parámetros de tipo introducida por
   **PEP 695**. Se agregó el parámetro "infer_variance".

class typing.TypeVarTuple(name)

   Type variable tuple. A specialized form of type variable that
   enables *variadic* generics.

   Las tuplas de variables de tipo se pueden declarar en listas de
   parámetros de tipo usando un solo asterisco ("*") antes del nombre:

      def move_first_element_to_last[T, *Ts](tup: tuple[T, *Ts]) -> tuple[*Ts, T]:
          return (*tup[1:], tup[0])

   O invocando explícitamente el constructor "TypeVarTuple":

      T = TypeVar("T")
      Ts = TypeVarTuple("Ts")

      def move_first_element_to_last(tup: tuple[T, *Ts]) -> tuple[*Ts, T]:
          return (*tup[1:], tup[0])

   Una variable de tipo normal permite parametrizar con un solo tipo.
   Una tupla de variables de tipo, en contraste, permite la
   parametrización con un número *arbitrario* de tipos, al actuar como
   un número *arbitrario* de variables de tipo envueltas en una tupla.
   Por ejemplo:

      # T is bound to int, Ts is bound to ()
      # Return value is (1,), which has type tuple[int]
      move_first_element_to_last(tup=(1,))

      # T is bound to int, Ts is bound to (str,)
      # Return value is ('spam', 1), which has type tuple[str, int]
      move_first_element_to_last(tup=(1, 'spam'))

      # T is bound to int, Ts is bound to (str, float)
      # Return value is ('spam', 3.0, 1), which has type tuple[str, float, int]
      move_first_element_to_last(tup=(1, 'spam', 3.0))

      # This fails to type check (and fails at runtime)
      # because tuple[()] is not compatible with tuple[T, *Ts]
      # (at least one element is required)
      move_first_element_to_last(tup=())

   Nótese el uso del operador de desempaquetado "*" en "tuple[T,
   *Ts]". Conceptualmente, puede pensarse en "Ts" como una tupla de
   variables de tipo "(T1, T2, ...)". "tuple[T, *Ts]" se convertiría
   en "tuple[T, *(T1, T2, ...)]", lo que es equivalente a "tuple[T,
   T1, T2, ...]". (Nótese que en versiones más antiguas de Python,
   ésto puede verse escrito usando en cambio "Unpack", en la forma
   "Unpack[Ts]".)

   Las tuplas de variables de tipo *siempre* deben descomprimirse.
   Esto ayuda a distinguir las tuplas de variables de tipo, de las
   variables de tipo normales:

      x: Ts          # Not valid
      x: tuple[Ts]   # Not valid
      x: tuple[*Ts]  # The correct way to do it

   Las tuplas de variables de tipo pueden ser utilizadas en los mismos
   contextos que las variables de tipo normales. Por ejemplo en
   definiciones de clases, argumentos y tipos de retorno:

      class Array[*Shape]:
          def __getitem__(self, key: tuple[*Shape]) -> float: ...
          def __abs__(self) -> "Array[*Shape]": ...
          def get_shape(self) -> tuple[*Shape]: ...

   Las tuplas de variables de tipo se pueden combinar sin problemas
   con variables de tipo normales:

      class Array[DType, *Shape]:  # This is fine
          pass

      class Array2[*Shape, DType]:  # This would also be fine
          pass

      class Height: ...
      class Width: ...

      float_array_1d: Array[float, Height] = Array()     # Totally fine
      int_array_2d: Array[int, Height, Width] = Array()  # Yup, fine too

   Sin embargo, nótese que en una determinada lista de argumentos de
   tipo o de parámetros de tipo puede haber como máximo una tupla de
   variables de tipo:

      x: tuple[*Ts, *Ts]            # Not valid
      class Array[*Shape, *Shape]:  # Not valid
          pass

   Finalmente, una tupla de variables de tipo desempaquetada puede ser
   utilizada como la anotación de tipo de "*args":

      def call_soon[*Ts](
          callback: Callable[[*Ts], None],
          *args: *Ts
      ) -> None:
          ...
          callback(*args)

   En contraste con las anotaciones no-desempaquetadas de "*args", por
   ej. "*args: int", que especificaría que *todos* los argumentos son
   "int" - "*args: *Ts" permite referenciar los tipos de los
   argumentos *individuales* en "*args". Aquí, ésto permite asegurarse
   de que los tipos de los "*args" que son pasados a "call_soon"
   calcen con los tipos de los argumentos (posicionales) de
   "callback".

   Véase **PEP 646** para obtener más detalles sobre las tuplas de
   variables de tipo.

   __name__

      El nombre de la tupla de variables de tipo.

   Added in version 3.11.

   Distinto en la versión 3.12: Ahora es posible declarar tuplas de
   variables de tipo utilizando la sintaxis de parámetros de tipo
   introducida por **PEP 695**.

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

   Parameter specification variable.  A specialized version of type
   variables.

   En las listas de parámetros de tipo, las especificaciones de
   parámetros se pueden declarar con dos asteriscos ("**"):

      type IntFunc[**P] = Callable[P, int]

   Para compatibilidad con Python 3.11 y versiones anteriores, los
   objetos "ParamSpec" también se pueden crear de la siguiente manera:

      P = ParamSpec('P')

   Las variables de especificación de parámetros existen
   principalmente para el beneficio de los validadores 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
   validador 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
      import logging

      def add_logging[T, **P](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

   Without "ParamSpec", the simplest way to annotate this previously
   was to use a "TypeVar" with upper bound "Callable[..., Any]".
   However this causes two problems:

   1. El validador 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 validador 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".

   __name__

      El nombre de la especificación del parámetro.

   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.

   Added in version 3.10.

   Distinto en la versión 3.12: Las especificaciones de parámetros
   ahora se pueden declarar utilizando la sintaxis de parámetros de
   tipo introducida por **PEP 695**.

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

     * "Concatenate"

     * Anotaciones en objetos invocables

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
   validadores de tipo estático.

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

      >>> from typing import ParamSpec, get_origin
      >>> P = ParamSpec("P")
      >>> get_origin(P.args) is P
      True
      >>> get_origin(P.kwargs) is P
      True

   Added in version 3.10.

class typing.TypeAliasType(name, value, *, type_params=())

   El tipo de alias de tipo creado a través de la declaración "type".

   Por ejemplo:

      >>> type Alias = int
      >>> type(Alias)
      <class 'typing.TypeAliasType'>

   Added in version 3.12.

   __name__

      El nombre del alias de tipo:

         >>> type Alias = int
         >>> Alias.__name__
         'Alias'

   __module__

      El módulo en el que se definió el alias de tipo:

         >>> type Alias = int
         >>> Alias.__module__
         '__main__'

   __type_params__

      Los parámetros de tipo del alias de tipo, o una tupla vacía si
      el alias no es genérico:

         >>> type ListOrSet[T] = list[T] | set[T]
         >>> ListOrSet.__type_params__
         (T,)
         >>> type NotGeneric = int
         >>> NotGeneric.__type_params__
         ()

   __value__

      El valor del alias de tipo. Se evalúa de forma diferida, por lo
      que los nombres utilizados en la definición del alias no se
      resuelven hasta que se accede al atributo "__value__":

         >>> type Mutually = Recursive
         >>> type Recursive = Mutually
         >>> Mutually
         Mutually
         >>> Recursive
         Recursive
         >>> Mutually.__value__
         Recursive
         >>> Recursive.__value__
         Mutually


Otras directivas especiales
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Estas funciones y clases no se deben utilizar directamente como
anotaciones. Su finalidad es servir de bloques de construcción para
crear y declarar tipos.

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.

   La clase resultante tiene un atributo extra "__annotations__" que
   proporciona un diccionario que mapea el nombre de los campos con
   sus respectivos tipos. (Los nombres de los campos están en el
   atributo "_fields" y sus valores por defecto en el atributo
   "_field_defaults", ambos parte de la API "namedtuple()".)

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

   Las subclases de "NamedTuple" pueden ser genéricas:

      class Group[T](NamedTuple):
          key: T
          group: list[T]

   Uso retrocompatible:

      # For creating a generic NamedTuple on Python 3.11
      T = TypeVar("T")

      class Group(NamedTuple, Generic[T]):
          key: T
          group: list[T]

      # A functional syntax is also supported
      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.

   Distinto en la versión 3.11: Se agrega soporte para *namedtuples*
   genéricas.

class typing.NewType(name, tp)

   Clase auxiliar para crear tipos distintos con bajo consumo de
   recursos.

   Un validador de tipos considera que un "NewType" es un tipo
   distinto. Sin embargo, en tiempo de ejecución, llamar a un
   "NewType" devuelve su argumento sin cambios.

   Uso:

      UserId = NewType('UserId', int)  # Declare the NewType "UserId"
      first_user = UserId(1)  # "UserId" returns the argument unchanged at runtime

   __module__

      El módulo en el que se define el nuevo tipo.

   __name__

      El nombre del nuevo tipo.

   __supertype__

      El tipo en el que se basa el nuevo tipo.

   Added in version 3.5.2.

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

class typing.Protocol(Generic)

   Clase base para clases de protocolo.

   Las clases de 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()" (descrito 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[T](Protocol):
          def meth(self) -> T:
              ...

   En el código que necesita ser compatible con Python 3.11 o
   anterior, los protocolos genéricos se pueden escribir de la
   siguiente manera:

      T = TypeVar("T")

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

   Added in version 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()" comprobará únicamente la presencia de los
     métodos o atributos requeridos, no sus firmas de tipo o tipos.
     Por ejemplo, "ssl.SSLObject" es una clase, por lo tanto, pasa una
     comprobación "issubclass()" contra Callable. Sin embargo, el
     método "ssl.SSLObject.__init__" existe únicamente para generar un
     "TypeError" con un mensaje más informativo, por lo que es
     imposible llamar (instanciar) "ssl.SSLObject".

   Nota:

     Una verificación "isinstance()" contra un protocolo comprobable
     en tiempo de ejecución puede ser sorprendentemente lenta en
     comparación con una verificación "isinstance()" contra una clase
     que no es de protocolo. Considere utilizar expresiones
     alternativas como llamadas "hasattr()" para comprobaciones
     estructurales en código sensible al rendimiento.

   Added in version 3.8.

   Distinto en la versión 3.12: La implementación interna de las
   comprobaciones de "isinstance()" con protocolos que se pueden
   comprobar en tiempo de ejecución ahora utiliza
   "inspect.getattr_static()" para buscar atributos (anteriormente, se
   utilizaba "hasattr()"). Como resultado, algunos objetos que solían
   considerarse instancias de un protocolo que se podía comprobar en
   tiempo de ejecución ya no se consideran instancias de ese protocolo
   en Python 3.12+, y viceversa. Es poco probable que la mayoría de
   los usuarios se vean afectados por este cambio.

   Distinto en la versión 3.12: Los miembros de un protocolo que se
   pueden comprobar en tiempo de ejecución ahora se consideran
   "congelados" en tiempo de ejecución tan pronto como se crea la
   clase. La aplicación de parches de  atributos en un protocolo que
   se puede comprobar en tiempo de ejecución seguirá funcionando, pero
   no tendrá ningún impacto en las comprobaciones de "isinstance()"
   que comparan objetos con el protocolo. Consulte "¿Qué hay de nuevo
   en Python 3.12" para obtener más detalles.

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')

   Para permitir el uso de esta característica con versiones más
   antiguas de Python que no tienen soporte para **PEP 526**,
   "TypedDict" soporta adicionalmente dos formas sintácticas
   equivalentes:

   * El uso de un "dict" literal como segundo argumento:

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

   * El uso de argumentos nombrados:

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

     Deprecated since version 3.11, will be removed in version 3.13:
     La sintaxis de argumentos nombrados está obsoleta desde la
     versión 3.11 y será removida en la versión 3.13. Además, podría
     no estar soportada por los validadores estáticos de tipo.

   This functional syntax allows defining keys which are not valid
   identifiers, for example because they are keywords or contain
   hyphens, or when key names must not be mangled like regular private
   names:

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

      class Definition(TypedDict):
          __schema: str  # mangled to `_Definition__schema`

      # OK, functional syntax
      Point2D = TypedDict('Point2D', {'in': int, 'x-y': int})
      Definition = TypedDict('Definition', {'__schema': str})  # not mangled

   De forma predeterminada, todas las llaves deben estar presentes en
   un "TypedDict". Es posible marcar llaves individuales como *no
   requeridas* utilizando "NotRequired":

      class Point2D(TypedDict):
          x: int
          y: int
          label: NotRequired[str]

      # Alternative syntax
      Point2D = TypedDict('Point2D', {'x': int, 'y': int, 'label': NotRequired[str]})

   Esto significa que en un "TypedDict" que sea una instancia de
   "Point2D", será posible omitir la llave "label".

   Además, es posible marcar todas las llaves como no-requeridas por
   defecto, al especificar un valor de "False" en el argumento
   *total*:

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

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

   Esto significa que un "TypedDict" "Point2D" puede tener cualquiera
   de las llaves omitidas. Solo se espera que un validador 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.

   Las llaves individuales de un "TypedDict" "total=False" pueden ser
   marcadas como requeridas utilizando "Required":

      class Point2D(TypedDict, total=False):
          x: Required[int]
          y: Required[int]
          label: str

      # Alternative syntax
      Point2D = TypedDict('Point2D', {
          'x': Required[int],
          'y': Required[int],
          'label': str
      }, total=False)

   Es posible que un tipo "TypedDict" herede de uno o más tipos
   "TypedDict" usando la sintaxis de clase. Uso:

      class Point3D(Point2D):
          z: int

   "Point3D" tiene tres elementos: "x", "y" y "z". Lo que es
   equivalente a la siguiente definición:

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

   Un "TypedDict" no puede heredar de una clase que no sea una
   subclase de "TypedDict", exceptuando "Generic". Por ejemplo:

      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

   Un "TypedDict" puede ser genérico:

      class Group[T](TypedDict):
          key: T
          group: list[T]

   Para crear un "TypedDict" genérico que sea compatible con Python
   3.11 o anterior, herede de "Generic" explícitamente:

      T = TypeVar("T")

      class Group(TypedDict, Generic[T]):
          key: T
          group: list[T]

   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__" proporciona el valor del argumento "total".
      Ejemplo:

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

      This attribute reflects *only* the value of the "total" argument
      to the current "TypedDict" class, not whether the class is
      semantically total. For example, a "TypedDict" with "__total__"
      set to "True" may have keys marked with "NotRequired", or it may
      inherit from another "TypedDict" with "total=False". Therefore,
      it is generally better to use "__required_keys__" and
      "__optional_keys__" for introspection.

   __required_keys__

      Added in version 3.9.

   __optional_keys__

      "Point2D.__required_keys__" y "Point2D.__optional_keys__"
      retornan objetos de la clase "frozenset", que contienen las
      llaves requeridas y no requeridas, respectivamente.

      Las llaves marcadas con "Required" siempre aparecerán en
      "__required_keys__" y las llaves marcadas con "NotRequired"
      siempre aparecerán en "__optional_keys__".

      Para compatibilidad con versiones anteriores de Python 3.10,
      también es posible usar la herencia para declarar claves
      obligatorias y no obligatorias en el mismo "TypedDict". Esto se
      hace declarando un "TypedDict" con un valor para el argumento
      "total" y luego heredando de él en otro "TypedDict" con un valor
      diferente para "total":

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

      Added in version 3.9.

      Nota:

        If "from __future__ import annotations" is used or if
        annotations are given as strings, annotations are not
        evaluated when the "TypedDict" is defined. Therefore, the
        runtime introspection that "__required_keys__" and
        "__optional_keys__" rely on may not work properly, and the
        values of the attributes may be incorrect.

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

   Added in version 3.8.

   Distinto en la versión 3.11: Se agrega soporte para marcar llaves
   individuales como "Required" o "NotRequired". Véase **PEP 655**.

   Distinto en la versión 3.11: Se agrega soporte para "TypedDict"
   genéricos.


Protocolos
----------

El módulo de tipado proporciona los siguientes protocolos. Todos están
decorados 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__".

   Added in version 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.


ABC para trabajar con IO
------------------------

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


Funciones y decoradores
-----------------------

typing.cast(typ, val)

   Convertir un valor a un 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.assert_type(val, typ, /)

   Solicitar a un validador de tipos que confirme que *val* tiene
   *typ* por tipo inferido.

   En tiempo de ejecución esto no hace nada: devuelve el primer
   argumento sin cambios, sin verificaciones ni efectos secundarios,
   sin importar el tipo real del argumento.

   Cuando un validador de tipo estático encuentra una llamada a
   "assert_type()", emite un error si el valor no es del tipo
   especificado:

      def greet(name: str) -> None:
          assert_type(name, str)  # OK, inferred type of `name` is `str`
          assert_type(name, int)  # type checker error

   Esta función es útil para asegurarse de que la comprensión que el
   validador de tipos tiene sobre un *script* está alineada con las
   intenciones de le desarrolladores:

      def complex_function(arg: object):
          # Do some complex type-narrowing logic,
          # after which we hope the inferred type will be `int`
          ...
          # Test whether the type checker correctly understands our function
          assert_type(arg, int)

   Added in version 3.11.

typing.assert_never(arg, /)

   Solicitar a un validador estático de tipos confirmar que una línea
   de código no es alcanzable.

   Por ejemplo:

      def int_or_str(arg: int | str) -> None:
          match arg:
              case int():
                  print("It's an int")
              case str():
                  print("It's a str")
              case _ as unreachable:
                  assert_never(unreachable)

   Aquí, las anotaciones permiten al validador de tipos inferir que el
   último caso nunca puede ejecutarse, porque "arg" es un "int" o un
   "str", y ambas opciones están cubiertas por los casos anteriores.

   Si un validador de tipos encuentra que una llamada a
   "assert_never()" es alcanzable, emitirá un error. Por ejemplo, si
   la anotación de tipo para "arg" fuese en cambio "int | str |
   float", el validador de tipos emitiría un error que indicaría que
   "unreachable" es de tipo "float". Para que una llamada a
   "assert_never" pase la verificación de tipos, el tipo inferido del
   argumento pasado debe ser el tipo inferior, "Never", y nada más.

   En tiempo de ejecución, ésto lanza una excepción cuando es llamado.

   Ver también:

     Unreachable Code and Exhaustiveness Checking has more information
     about exhaustiveness checking with static typing.

   Added in version 3.11.

typing.reveal_type(obj, /)

   Ask a static type checker to reveal the inferred type of an
   expression.

   When a static type checker encounters a call to this function, it
   emits a diagnostic with the inferred type of the argument. For
   example:

      x: int = 1
      reveal_type(x)  # Revealed type is "builtins.int"

   Ésto puede ser de utilidad cuando se desea *debuguear* cómo tu
   validador de tipos maneja una pieza particular de código.

   At runtime, this function prints the runtime type of its argument
   to "sys.stderr" and returns the argument unchanged (allowing the
   call to be used within an expression):

      x = reveal_type(1)  # prints "Runtime type is int"
      print(x)  # prints "1"

   Note that the runtime type may be different from (more or less
   specific than) the type statically inferred by a type checker.

   Most type checkers support "reveal_type()" anywhere, even if the
   name is not imported from "typing". Importing the name from
   "typing", however, allows your code to run without runtime errors
   and communicates intent more clearly.

   Added in version 3.11.

@typing.dataclass_transform(*, eq_default=True, order_default=False, kw_only_default=False, frozen_default=False, field_specifiers=(), **kwargs)

   Decorador para marcar un objeto como si proporcionara un
   comportamiento similar a "dataclass".

   "dataclass_transform" se puede utilizar para decorar una clase,
   metaclase o una función que sea en sí misma un decorador. La
   presencia de "@dataclass_transform()" le indica al validador de
   tipos estáticos que el objeto decorado realiza una "magia" en
   tiempo de ejecución que transforma una clase de manera similar a
   "@dataclasses.dataclass".

   Ejemplo de uso con una función decoradora:

      @dataclass_transform()
      def create_model[T](cls: type[T]) -> type[T]:
          ...
          return cls

      @create_model
      class CustomerModel:
          id: int
          name: str

   En una clase base:

      @dataclass_transform()
      class ModelBase: ...

      class CustomerModel(ModelBase):
          id: int
          name: str

   En una metaclase:

      @dataclass_transform()
      class ModelMeta(type): ...

      class ModelBase(metaclass=ModelMeta): ...

      class CustomerModel(ModelBase):
          id: int
          name: str

   Las clases "CustomerModel" definidas arribe serán tratadas por los
   validadores de tipo de forma similar a las clases que sean creadas
   con  "@dataclasses.dataclass". Por ejemplo, los validadores de tipo
   asumirán que estas clases tienen métodos "__init__" que aceptan
   "id" y "name".

   La clase, metaclase o función decorada puede aceptar los siguientes
   argumentos booleanos, de los cuales los validadores de tipos
   asumirán que tienen el mismo efecto que tendrían en el decorador
   "@dataclasses.dataclass": "init", "eq", "order", "unsafe_hash",
   "frozen", "match_args", "kw_only", y "slots". Debe ser posible
   evaluar estáticamente el valor de estos argumentos ("True" o
   "False").

   Es posible utilizar los argumentos del decorador
   "dataclass_transform" para personalizar los comportamientos por
   defecto de la clase, metaclase o función decorada:

   Parámetros:
      * **eq_default** (*bool*) -- Indica si se asume que el parámetro
        "eq" es "True" o "False" si el llamador lo omite. El valor
        predeterminado es "True".

      * **order_default** (*bool*) -- Indica si se asume que el
        parámetro "order" es "True" o "False" si el llamador lo omite.
        El valor predeterminado es "False".

      * **kw_only_default** (*bool*) -- Indica si se asume que el
        parámetro "kw_only" es "True" o "False" si el llamador lo
        omite. El valor predeterminado es "False".

      * **frozen_default** (*bool*) -- Indica si se asume que el
        parámetro "frozen" es "True" o "False" si el llamador lo
        omite. El valor predeterminado es "False". .. Agregado en la
        versión:: 3.12

      * **field_specifiers** (*tuple**[**Callable**[**...**,
        **Any**]**, **...**]*) -- Especifica una lista estática de
        clases o funciones admitidas que describen campos, parecido
        con "dataclasses.field()". El valor predeterminado es "()".

      * ****kwargs** (*Any*) -- Es posible pasar arbitrariamente otros
        argumentos nombrados para permitir posibles extensiones
        futuras.

   Los validadores de tipos reconocen los siguientes parámetros
   opcionales en los especificadores de campo:


   **Parámetros reconocidos para especificadores de campo**
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   +----------------------+----------------------------------------------------------------------------------+
   | Nombre del parámetro | Descripción                                                                      |
   |======================|==================================================================================|
   | "init"               | Indica si el campo debe incluirse en el método "__init__" sintetizado. Si no se  |
   |                      | especifica, el valor predeterminado de "init" es "True".                         |
   +----------------------+----------------------------------------------------------------------------------+
   | "default"            | Proporciona el valor predeterminado para el campo.                               |
   +----------------------+----------------------------------------------------------------------------------+
   | "default_factory"    | Proporciona una retrollamada en tiempo de ejecución que devuelve el valor        |
   |                      | predeterminado del campo. Si no se especifican "default" ni "default_factory",   |
   |                      | se supone que el campo no tiene un valor predeterminado y se le debe             |
   |                      | proporcionar un valor cuando se cree una instancia de la clase.                  |
   +----------------------+----------------------------------------------------------------------------------+
   | "factory"            | Un alias para el parámetro "default_factory" en los especificadores de campo.    |
   +----------------------+----------------------------------------------------------------------------------+
   | "kw_only"            | Indica si el campo debe marcarse como solo para palabras clave. Si es "True", el |
   |                      | campo será solo para palabras clave. Si es "False", no será solo para palabras   |
   |                      | clave. Si no se especifica, se utilizará el valor del parámetro "kw_only" en el  |
   |                      | objeto decorado con "dataclass_transform", o si no se especifica, se utilizará   |
   |                      | el valor de "kw_only_default" en "dataclass_transform".                          |
   +----------------------+----------------------------------------------------------------------------------+
   | "alias"              | Proporciona un nombre alternativo para el campo. Este nombre alternativo se      |
   |                      | utiliza en el método sintetizado "__init__".                                     |
   +----------------------+----------------------------------------------------------------------------------+

   En tiempo de ejecución, este decorador registra sus argumentos en
   el atributo "__dataclass_transform__" del objeto decorado. No tiene
   otro efecto en tiempo de ejecución.

   Véase **PEP 681** para más detalle.

   Added in version 3.11.

@typing.overload

   Decorador para crear funciones y métodos sobrecargados.

   El decorador "@overload" permite describir funciones y métodos que
   admiten múltiples combinaciones diferentes de tipos de argumentos.
   Una serie de definiciones decoradas con "@overload" debe ir seguida
   de exactamente una definición que no esté 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". Mientras tanto, la definición no
   decorada con "@overload" se usará en tiempo de ejecución, pero el
   validador de tipos debe ignorarla. En tiempo de ejecución, llamar a
   una función decorada con "@overload" directamente generará
   "NotImplementedError".

   Un ejemplo de sobrecarga que proporciona un tipo más preciso que el
   que se puede expresar mediante 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 goes here

   Véase **PEP 484** para más detalle y comparación con otras
   semánticas de tipado.

   Distinto en la versión 3.11: Ahora es posible introspectar en
   tiempo de ejecución las funciones sobrecargadas utilizando
   "get_overloads()".

typing.get_overloads(func)

   Devuelve una secuencia de definiciones decoradas con "@overload"
   para *func*.

   *func* es el objeto de función para la implementación de la función
   sobrecargada. Por ejemplo, dada la definición de "process" en la
   documentación de "@overload", "get_overloads(process)" devolverá
   una secuencia de tres objetos de función para las tres sobrecargas
   definidas. Si se llama en una función sin sobrecargas,
   "get_overloads()" devuelve una secuencia vacía.

   "get_overloads()" puede ser utilizada para introspectar en tiempo
   de ejecución una función sobrecargada.

   Added in version 3.11.

typing.clear_overloads()

   Borra todas las sobrecargas registradas en el registro interno.

   Esto se puede utilizar para recuperar la memoria utilizada por el
   registro.

   Added in version 3.11.

@typing.final

   Decorador para indicar métodos finales y clases finales.

   Decorar un método con "@final" indica a un validador de tipos que
   el método no se puede anular en una subclase. Decorar una clase con
   "@final" indica que no se puede subclasificar.

   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.

   Added in version 3.8.

   Distinto en la versión 3.11: El decorador intentará ahora
   establecer un atributo "__final__" como "True" en el objeto
   decorado. Por lo tanto, se puede utilizar una comprobación como "if
   getattr(obj, “__final__”, False)" en tiempo de ejecución para
   determinar si un objeto "obj" se ha marcado como final. Si el
   objeto decorado no admite la configuración de atributos, el
   decorador devuelve el objeto sin cambios sin lanzar una excepción.

@typing.no_type_check

   Un decorador para indicar que las 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 y
   clases definidos en esa clase (pero no a los métodos definidos en
   sus superclases o subclases). Los validadores de tipos ignorarán
   todas las anotaciones en una función o clase con este decorador.

   "@no_type_check" muta el objeto decorado en su lugar.

@typing.no_type_check_decorator

   Decorador para dar a otro decorador el efecto "no_type_check()".

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

@typing.override

   Decorador para indicar que un método en una subclase está destinado
   a anular un método o atributo en una superclase.

   Los validadores de tipos deberían emitir un error si un método
   decorado con "@override" no anula nada. Esto ayuda a evitar errores
   que pueden ocurrir cuando se modifica una clase base sin un cambio
   equivalente en una clase secundaria.

   Por ejemplo:

      class Base:
          def log_status(self) -> None:
              ...

      class Sub(Base):
          @override
          def log_status(self) -> None:  # Okay: overrides Base.log_status
              ...

          @override
          def done(self) -> None:  # Error reported by type checker
              ...

   No hay ninguna comprobación en tiempo de ejecución de esta
   propiedad.

   El decorador intentará establecer un atributo "__override__" en
   "True" en el objeto decorado. Por lo tanto, una comprobación como
   "if getattr(obj, “__override__”, False)" se puede utilizar en
   tiempo de ejecución para determinar si un objeto "obj" ha sido
   marcado como anulado. Si el objeto decorado no admite la
   configuración de atributos, el decorador devuelve el objeto sin
   cambios sin generar una excepción.

   Vea **PEP 681** para más información.

   Added in version 3.12.

@typing.type_check_only

   Decorador para marcar 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.

   This is often the same as "obj.__annotations__", but this function
   makes the following changes to the annotations dictionary:

   * Forward references encoded as string literals or "ForwardRef"
     objects are handled by evaluating them in *globalns*, *localns*,
     and (where applicable) *obj*'s type parameter namespace. If
     *globalns* or *localns* is not given, appropriate namespace
     dictionaries are inferred from *obj*.

   * "None" is replaced with "types.NoneType".

   * If "@no_type_check" has been applied to *obj*, an empty
     dictionary is returned.

   * If *obj* is a class "C", the function returns a dictionary that
     merges annotations from "C"'s base classes with those on "C"
     directly. This is done by traversing "C.__mro__" and iteratively
     combining "__annotations__" dictionaries. Annotations on classes
     appearing earlier in the *method resolution order* always take
     precedence over annotations on classes appearing later in the
     method resolution order.

   * The function recursively replaces all occurrences of
     "Annotated[T, ...]" with "T", unless *include_extras* is set to
     "True" (see "Annotated" for more information).

   See also "inspect.get_annotations()", a lower-level function that
   returns annotations more directly.

   Nota:

     If any forward references in the annotations of *obj* are not
     resolvable or are not valid Python code, this function will raise
     an exception such as "NameError". For example, this can happen
     with imported type aliases that include forward references, or
     with names imported under "if TYPE_CHECKING".

   Distinto en la versión 3.9: Se agregó el parámetro "include_extras"
   como parte de **PEP 593**. Consulte la documentación en "Annotated"
   para obtener más información.

   Distinto en la versión 3.11: Anteriormente, se agregaba
   "Optional[t]" en las anotaciones de funciones o métodos si se
   establecía un valor por defecto igual a "None". Ahora la anotación
   es retornada sin cambios.

typing.get_origin(tp)

   Obtiene la versión sin suscripción de un tipo: para un objeto de
   tipado de la forma "X[Y, Z, ...]" devuelve "X".

   Si "X" es un alias de módulo de tipado para una clase incorporada o
   "collections", se normalizará a la clase original. Si "X" es una
   instancia de "ParamSpecArgs" o "ParamSpecKwargs", devuelve la
   "ParamSpec" subyacente. Devuelve "None" para objetos no soportados.

   Por ejemplo:

      assert get_origin(str) is None
      assert get_origin(Dict[str, int]) is dict
      assert get_origin(Union[int, str]) is Union
      assert get_origin(Annotated[str, "metadata"]) is Annotated
      P = ParamSpec('P')
      assert get_origin(P.args) is P
      assert get_origin(P.kwargs) is P

   Added in version 3.8.

typing.get_args(tp)

   Obtiene los argumentos de tipo con todas las sustituciones
   realizadas: para un objeto de tipo con la forma "X[Y, Z, ...]"
   devuelve "(Y, Z, ...)".

   Si "X" es una unión o "Literal" contenida en otro tipo genérico, el
   orden de "(Y, Z, ...)" puede ser diferente del orden de los
   argumentos originales "[Y, Z, ...]" debido al almacenamiento en
   caché de tipos. Devuelve "()" para objetos no soportados.

   Por ejemplo:

      assert get_args(int) == ()
      assert get_args(Dict[int, str]) == (int, str)
      assert get_args(Union[int, str]) == (int, str)

   Added in version 3.8.

typing.is_typeddict(tp)

   Compruebe si un tipo es "TypedDict".

   Por ejemplo:

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

      assert is_typeddict(Film)
      assert not is_typeddict(list | str)

      # TypedDict is a factory for creating typed dicts,
      # not a typed dict itself
      assert not is_typeddict(TypedDict)

   Added in version 3.10.

class typing.ForwardRef

   Clase utilizada para la representación interna de tipado de cadenas
   de caracteres en referencias futuras.

   Por ejemplo, "List["SomeClass"]" se transforma implícitamente en
   "List[ForwardRef("SomeClass")]". "ForwardRef" no debe ser
   instanciado por un usuario, pero puede ser utilizado 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]".

   Added in version 3.7.4.


Constantes
----------

typing.TYPE_CHECKING

   Una constante especial que los validadores de tipos estáticos de
   terceros asumen como "True". Es "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:

     Si se utiliza "from __future__ import annotations", las
     anotaciones no son evaluadas al momento de la definición de
     funciones. En cambio, serán almacenadas como cadenas de texto en
     "__annotations__". Ésto vuelve innecesario el uso de comillas
     alrededor de la anotación (véase **PEP 563**).

   Added in version 3.5.2.


Alias obsoletos
---------------

Este módulo define varios alias obsoletos para clases de biblioteca
estándar preexistentes. Originalmente, se incluyeron en el módulo de
tipado para admitir la parametrización de estas clases genéricas
mediante "[]". Sin embargo, los alias se volvieron redundantes en
Python 3.9 cuando las clases preexistentes correspondientes se
mejoraron para admitir "[]" (vea **PEP 585**).

Los tipos redundantes están obsoletos a partir de Python 3.9. Sin
embargo, si bien los alias pueden eliminarse en algún momento,
actualmente no se planea eliminarlos. Por lo tanto, el intérprete no
emite advertencias de obsolescencia para estos alias.

Si en algún momento se decide eliminar estos alias obsoletos, el
intérprete emitirá una advertencia de desuso durante al menos dos
versiones antes de la eliminación. Se garantiza que los alias
permanecerán en el módulo de tipificación sin advertencias de desuso
hasta al menos Python 3.14.

Se recomienda a los validadores de tipos que marquen los usos de los
tipos obsoletos si el programa que están verificando apunta a una
versión mínima de Python 3.9 o más reciente.


Alias de tipos integrados
~~~~~~~~~~~~~~~~~~~~~~~~~

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

   Alias obsoleto de "dict".

   Note that to annotate arguments, it is preferred to use an abstract
   collection type such as "Mapping" rather than to use "dict" or
   "typing.Dict".

   Obsoleto desde la versión 3.9: "builtins.dict" ahora soporta
   subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

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

   Alias obsoleto de "list".

   Note that to annotate arguments, it is preferred to use an abstract
   collection type such as "Sequence" or "Iterable" rather than to use
   "list" or "typing.List".

   Obsoleto desde la versión 3.9: "builtins.list" ahora soporta
   subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

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

   Alias obsoleto de "builtins.set".

   Note that to annotate arguments, it is preferred to use an abstract
   collection type such as "collections.abc.Set" rather than to use
   "set" or "typing.Set".

   Obsoleto desde la versión 3.9: "builtins.set" ahora soporta
   subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

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

   Alias obsoleto de "builtins.frozenset".

   Obsoleto desde la versión 3.9: "builtins.frozenset" ahora soporta
   subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

typing.Tuple

   Alias obsoleto de "tuple".

   "tuple" y "Tuple" son casos especiales en el sistema de tipos;
   consulte Anotaciones en tuplas para más detalles.

   Obsoleto desde la versión 3.9: "builtins.tuple" ahora soporta el
   uso de subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

class typing.Type(Generic[CT_co])

   Alias obsoleto de "type".

   Vea El tipo de objetos de clase para obtener detalles sobre el uso
   de "type" o "typing.Type" en anotaciones de tipo.

   Added in version 3.5.2.

   Obsoleto desde la versión 3.9: "builtins.type" ahora soporta el uso
   de subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.


Alias de tipos en "collections"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

   Alias obsoleto de "collections.defaultdict".

   Added in version 3.5.2.

   Obsoleto desde la versión 3.9: "collections.defaultdict" ahora
   soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

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

   Alias obsoleto de "collections.OrderedDict".

   Added in version 3.7.2.

   Obsoleto desde la versión 3.9: "collections.OrderedDict" ahora
   soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

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

   Alias obsoleto de "collections.ChainMap".

   Added in version 3.6.1.

   Obsoleto desde la versión 3.9: "collections.ChainMap" ahora soporta
   subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

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

   Alias obsoleto de "collections.Counter".

   Added in version 3.6.1.

   Obsoleto desde la versión 3.9: "collections.Counter" ahora soporta
   subíndices ("[]")`. Véase **PEP 585** y Tipo Alias Genérico.

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

   Alias obsoleto de "collections.deque".

   Added in version 3.6.1.

   Obsoleto desde la versión 3.9: "collections.deque" ahora soporta
   subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.


Alias ​​a otros tipos concretos
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   Deprecated since version 3.8, will be removed in version 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

   Alias ​​obsoletos correspondientes a los tipos de retorno
   "re.compile()" y "re.match()".

   Estos tipos (y las funciones correspondientes) son genéricos sobre
   "AnyStr". "Pattern" se puede especializar como "Pattern[str]" o
   "Pattern[bytes]"; "Match" se puede especializar como "Match[str]" o
   "Match[bytes]".

   Deprecated since version 3.8, will be removed in version 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

   Alias obsoleto para "str".

   Se indica "Text" para proporcionar compatibilidad con versiones de
   código posteriores a Python 2: en Python 2, "Text" es un alias para
   "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'

   Added in version 3.5.2.

   Obsoleto desde la versión 3.11: Python 2 ya no es compatible, y la
   mayoría de los validadores de tipos tampoco admiten la verificación
   de tipos de código Python 2. La eliminación del alias no está
   planeada actualmente, pero se recomienda a los usuarios utilizar
   "str" en lugar de "Text".


Alias de ABCs de contenedores en "collections.abc"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

class typing.AbstractSet(Collection[T_co])

   Alias obsoleto de "collections.abc.Set".

   Obsoleto desde la versión 3.9: "collections.abc.Set" ahora soporta
   subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

class typing.ByteString(Sequence[int])

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

   Deprecated since version 3.9, will be removed in version 3.14:
   Preferiblemente use "collections.abc.Buffer", o una unión como
   "bytes | bytearray | memoryview".

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

   Alias obsoleto de "collections.abc.Collection".

   Added in version 3.6.

   Obsoleto desde la versión 3.9: "collections.abc.Collection" ahora
   soporta la sintaxis de subíndice ("[]"). Véase **PEP 585** y Tipo
   Alias Genérico.

class typing.Container(Generic[T_co])

   Alias obsoleto de "collections.abc.Container".

   Obsoleto desde la versión 3.9: "collections.abc.Container" ahora
   soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

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

   Alias obsoleto de "collections.abc.ItemsView".

   Obsoleto desde la versión 3.9: "collections.abc.ItemsView" ahora
   soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

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

   Alias obsoleto de "collections.abc.KeysView".

   Obsoleto desde la versión 3.9: "collections.abc.KeysView" ahora
   soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

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

   Alias obsoleto de "collections.abc.Mapping".

   Obsoleto desde la versión 3.9: "collections.abc.Mapping" ahora
   soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

class typing.MappingView(Sized)

   Alias obsoleto de "collections.abc.MappingView".

   Obsoleto desde la versión 3.9: "collections.abc.MappingView" ahora
   soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

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

   Alias obsoleto de "collections.abc.MutableMapping".

   Obsoleto desde la versión 3.9: "collections.abc.MutableMapping"
   ahora soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias
   Genérico.

class typing.MutableSequence(Sequence[T])

   Alias obsoleto de "collections.abc.MutableSequence".

   Obsoleto desde la versión 3.9: "collections.abc.MutableSequence"
   ahora soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias
   Genérico.

class typing.MutableSet(AbstractSet[T])

   Alias obsoleto de "collections.abc.MutableSet".

   Obsoleto desde la versión 3.9: "collections.abc.MutableSet" ahora
   soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

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

   Alias obsoleto de "collections.abc.Sequence".

   Obsoleto desde la versión 3.9: "collections.abc.Sequence" ahora
   soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

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

   Alias obsoleto de "collections.abc.ValuesView".

   Obsoleto desde la versión 3.9: "collections.abc.ValuesView" ahora
   soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.


Alias para ABCs asíncronos en "collections.abc"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

class typing.Coroutine(Awaitable[ReturnType], Generic[YieldType, SendType, ReturnType])

   Alias obsoleto de "collections.abc.Coroutine".

   See Annotating generators and coroutines for details on using
   "collections.abc.Coroutine" and "typing.Coroutine" in type
   annotations.

   Added in version 3.5.3.

   Obsoleto desde la versión 3.9: "collections.abc.Coroutine" ahora
   soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

class typing.AsyncGenerator(AsyncIterator[YieldType], Generic[YieldType, SendType])

   Alias obsoleto de "collections.abc.AsyncGenerator".

   See Annotating generators and coroutines for details on using
   "collections.abc.AsyncGenerator" and "typing.AsyncGenerator" in
   type annotations.

   Added in version 3.6.1.

   Obsoleto desde la versión 3.9: "collections.abc.AsycGenerator"
   ahora soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias
   Genérico.

class typing.AsyncIterable(Generic[T_co])

   Alias obsoleto de "collections.abc.AsyncIterable".

   Added in version 3.5.2.

   Obsoleto desde la versión 3.9: "collections.abc.AsyncIterable"
   ahora soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias
   Genérico.

class typing.AsyncIterator(AsyncIterable[T_co])

   Alias obsoleto de "collections.abc.AsyncIterator".

   Added in version 3.5.2.

   Obsoleto desde la versión 3.9: "collections.abc.AsyncIterator"
   ahora soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias
   Genérico.

class typing.Awaitable(Generic[T_co])

   Alias obsoleto de "collections.abc.Awaitable".

   Added in version 3.5.2.

   Obsoleto desde la versión 3.9: "collections.abc.Awaitable" ahora
   soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.


Alias a otros ABCs en "collections.abc"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

class typing.Iterable(Generic[T_co])

   Alias obsoleto de "collections.abc.Iterable".

   Obsoleto desde la versión 3.9: "collections.abc.Iterable" ahora
   soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

class typing.Iterator(Iterable[T_co])

   Alias obsoleto de "collections.abc.Iterator".

   Obsoleto desde la versión 3.9: "collections.abc.Iterator" ahora
   soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

typing.Callable

   Alias obsoleto de "collections.abc.Callable".

   Vea Anotaciones en objetos invocables para información detallada de
   cómo usar "collections.abc.Callable" y "typing.Callable" en
   anotaciones de tipo.

   Obsoleto desde la versión 3.9: "collections.abc.Callable" ahora
   soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

   Distinto en la versión 3.10: "Callable" ahora es compatible con
   "ParamSpec" y "Concatenate". Consulte **PEP 612** para obtener más
   información.

class typing.Generator(Iterator[YieldType], Generic[YieldType, SendType, ReturnType])

   Alias obsoleto de "collections.abc.Generator".

   See Annotating generators and coroutines for details on using
   "collections.abc.Generator" and "typing.Generator" in type
   annotations.

   Obsoleto desde la versión 3.9: "collections.abc.Generator" ahora
   soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

class typing.Hashable

   Alias obsoleto de "collections.abc.Hashable".

   Obsoleto desde la versión 3.12: Use directamente
   "collections.abc.Hashable" en su lugar.

class typing.Reversible(Iterable[T_co])

   Alias obsoleto de "collections.abc.Reversible".

   Obsoleto desde la versión 3.9: "collections.abc.Reversible" ahora
   soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias Genérico.

class typing.Sized

   Alias obsoleto de "collections.abc.Sized".

   Obsoleto desde la versión 3.12: Use directamente
   "collections.abc.Sized" en su lugar.


Alias de ABCs "contextlib"
~~~~~~~~~~~~~~~~~~~~~~~~~~

class typing.ContextManager(Generic[T_co])

   Alias obsoleto de "contextlib.AbstractContextManager".

   Added in version 3.5.4.

   Obsoleto desde la versión 3.9: "contextlib.AbstractContextManager"
   ahora soporta subíndices ("[]"). Véase **PEP 585** y Tipo Alias
   Genérico.

class typing.AsyncContextManager(Generic[T_co])

   Alias obsoleto de "contextlib.AbstractAsyncContextManager".

   Added in version 3.6.2.

   Obsoleto desde la versión 3.9:
   "contextlib.AbstractAsyncContextManager" ahora soporta subíndices
   ("[]"). Véase **PEP 585** y Tipo Alias Genérico.


Línea de tiempo de obsolescencia de características principales
===============================================================

Algunas características de "typing" están obsoletas y podrán ser
removidas en versiones futuras de Python. Lo que sigue es una tabla
que resume las principales obsolescencias para su conveniencia. Ésto
está sujeto a cambio y no todas las obsolescencias están
representadas.

+---------------------------+---------------------------+---------------------------+---------------------------+
| Característica            | En desuso desde           | Eliminación proyectada    | PEP/issue                 |
|===========================|===========================|===========================|===========================|
| sub-módulos "typing.io" y | 3.8                       | 3.13                      | bpo-38291                 |
| "typing.re"               |                           |                           |                           |
+---------------------------+---------------------------+---------------------------+---------------------------+
| Versiones "typing" de     | 3.9                       | No decidido (ver Alias    | **PEP 585**               |
| colecciones estándares    |                           | obsoletos para más        |                           |
|                           |                           | información)              |                           |
+---------------------------+---------------------------+---------------------------+---------------------------+
| "typing.ByteString"       | 3.9                       | 3.14                      | gh-91896                  |
+---------------------------+---------------------------+---------------------------+---------------------------+
| "typing.Text"             | 3.11                      | No decidido               | gh-92332                  |
+---------------------------+---------------------------+---------------------------+---------------------------+
| "typing.Hashable" y       | 3.12                      | No decidido               | gh-94309                  |
| "typing.Sized"            |                           |                           |                           |
+---------------------------+---------------------------+---------------------------+---------------------------+
| "typing.TypeAlias"        | 3.12                      | No decidido               | **PEP 695**               |
+---------------------------+---------------------------+---------------------------+---------------------------+
