typing — Support for type hints¶

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 tiene tipo 'str'
concat(b"foo", b"bar")  # OK, output tiene tipo 'bytes'
concat("foo", b"bar")   # Error, no se puede mezclar str y 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:

# Uso inválido de AnyStr:
# La variable de tipo se usa solo una vez en la firma de la función,
# por lo que el verificador de tipos no puede resolverla.
def greet_bad(cond: bool) -> AnyStr:
    return "hi there!" if cond else b"greetings!"

# La mejor manera de anotar esta función:
def greet_proper(cond: bool) -> str | bytes:
    return "hi there!" if cond else b"greetings!"

Deprecated since version 3.13, will be removed in version 3.18: Obsoleto en favor del nuevo type parameter syntax. Utilice class A[T: (str, bytes)]: ... en lugar de importar AnyStr. Consulte PEP 695 para obtener más detalles.

En Python 3.16, AnyStr se eliminará de typing.__all__ y se emitirán advertencias de desuso en tiempo de ejecución cuando se acceda a él o se importe desde typing. AnyStr se eliminará de typing en Python 3.18.

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 y NoReturn representan bottom type, un tipo que no tiene miembros.

Se pueden utilizar para indicar que una función nunca retorna, como sys.exit():

from typing import Never  # o NoReturn

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

O definir una función que nunca debe llamarse, ya que no hay argumentos válidos, como assert_never():

from typing import Never  # o NoReturn

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

def int_or_str(arg: int | str) -> None:
    never_call_me(arg)  # error del verificador de tipos
    match arg:
        case int():
            print("It's an int")
        case str():
            print("It's a str")
        case _:
            never_call_me(arg)  # OK, arg es del tipo Never (o NoReturn)

Never y NoReturn tienen el mismo significado en el sistema de tipos y los verificadores de tipos estáticos los tratan a ambos de manera equivalente.

Added in version 3.6.2: Se agregó NoReturn.

Added in version 3.11: Se agregó 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())  # Tipo revelado es "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" aún no existe,
# entonces tenemos que usar comillas para la referencia adelantada en Python <3.12.
# Usando ``TypeAlias`` le dice al verificador de tipos que es una declaración de tipo alias,
# no una asignacin de variable a un 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.

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

  However, this does not apply to unions referenced through a type alias, to avoid forcing evaluation of the underlying TypeAliasType:

  type A = Union[int, str]
  Union[A, float] != Union[int, str, float]
  

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

  Union[int] == int  # El constructor de hecho retorna 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.

Distinto en la versión 3.14: types.UnionType is now an alias for Union, and both Union[int, str] and int | str create instances of the same class. To check whether an object is a Union at runtime, use isinstance(obj, Union). For compatibility with earlier versions of Python, use get_origin(obj) is typing.Union or get_origin(obj) is types.UnionType.

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

# Utilice este bloqueo para garantizar que solo un hilo esté ejecutando una función
# en cualquier momento.
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:
        # Proporcione el bloqueo como primer argumento.
        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)

# No necesitamos pasar por la cerradura nosotros mismos gracias al decorador.
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]:  # siempre retorna True
    ...

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

open_helper('/some/path', 'r')      # Pasa el verificador de tipos
open_helper('/other/path', 'typo')  # Error en el verificador de tipos

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.

Additional details:

• The arguments must be literal values and there must be at least one.

• Nested Literal types are flattened, e.g.:

  assert Literal[Literal[1, 2], 3] == Literal[1, 2, 3]
  

  However, this does not apply to Literal types referenced through a type alias, to avoid forcing evaluation of the underlying TypeAliasType:

  type A = Literal[1, 2]
  assert Literal[A, 3] != Literal[1, 2, 3]
  

• Argumentos repetidos se omiten, p. ej.:

  assert Literal[1, 2, 1] == Literal[1, 2]
  

• When comparing literals, the argument order is ignored, e.g.:

  assert Literal[1, 2] == Literal[2, 1]
  

• You cannot subclass or instantiate a Literal.

• You cannot write Literal[X][Y].

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]] = {} # variable de clase
    damage: int = 10                     # variable de instancia

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, establece variable de clase en la instancia
Starship.stats = {}     # Ésto está OK

Added in version 3.5.3.

Distinto en la versión 3.13: Ahora ClassVar se puede anidar en Final y viceversa.

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 reportado por un verificador de tipos

class Connection:
    TIMEOUT: Final[int] = 10

class FastConnector(Connection):
    TIMEOUT = 1  # Error reportado por un verificador de tipos

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.13: Ahora Final se puede anidar en ClassVar y viceversa.

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.ReadOnly¶

Una construcción de tipificación especial para marcar un elemento de un TypedDict como de solo lectura.

Por ejemplo:

class Movie(TypedDict):
   title: ReadOnly[str]
   year: int

def mutate_movie(m: Movie) -> None:
   m["year"] = 1999  # allowed
   m["title"] = "The Matrix"  # error del verificador de tipos

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

Vea TypedDict y PEP 705 para más detalle.

Added in version 3.13.

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.

Using Annotated[T, x] as an annotation still allows for static typechecking of T, as type checkers will simply ignore the metadata x. In this way, Annotated differs from the @no_type_check decorator, which can also be used for adding annotations outside the scope of the typing system, but completely disables typechecking for a function or class.

La responsabilidad de interpretar los metadatos recae en la herramienta o biblioteca que encuentra una anotación Annotated. Una herramienta o biblioteca que encuentra un tipo Annotated puede examinar los elementos de metadatos para determinar si son de interés (por ejemplo, utilizando 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")
]

However, this does not apply to Annotated types referenced through a type alias, to avoid forcing evaluation of the underlying TypeAliasType:

type From3To10[T] = Annotated[T, ValueRange(3, 10)]
assert Annotated[From3To10[int], 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)]

# Cuando se utiliza en una anotación de tipo, un verificador de tipo tratará "V" de la misma manera que
# ``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'>

Tenga en cuenta que el uso de get_origin() devolverá el mismo Annotated:

>>> get_origin(Password)
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.TypeIs¶

Construcción de tipificación especial para marcar funciones de predicado de tipo definido por el usuario.

TypeIs se puede utilizar para anotar el tipo de retorno de una función de predicado de tipo definida por el usuario. TypeIs solo acepta un único argumento de tipo. En tiempo de ejecución, las funciones marcadas de esta manera deben devolver un valor booleano y tomar al menos un argumento posicional.

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

def is_str(val: str | float):
    # "isinstance" predicado de tipo
    if isinstance(val, str):
        # Tipo de ``val`` se reduce a ``str``
        ...
    else:
        # De lo contrario, el tipo de ``val`` se limita a ``float``.
        ...

A veces sería conveniente utilizar una función booleana definida por el usuario como predicado de tipo. Dicha función debería utilizar TypeIs[...] o TypeGuard como su tipo de retorno para alertar a los verificadores de tipos estáticos sobre esta intención. TypeIs suele tener un comportamiento más intuitivo que TypeGuard, pero no se puede utilizar cuando los tipos de entrada y salida son incompatibles (por ejemplo, list[object] a list[int]) o cuando la función no devuelve True para todas las instancias del tipo restringido.

El uso de -> TypeIs[NarrowedType] le indica al verificador de tipo estático que para una función determinada:

1. El valor de retorno es un booleano.

2. Si el valor de retorno es True, el tipo de su argumento es la intersección del tipo original del argumento y NarrowedType.

3. Si el valor de retorno es False, el tipo de su argumento se limita para excluir NarrowedType.

Por ejemplo:

from typing import assert_type, final, TypeIs

class Parent: pass
class Child(Parent): pass
@final
class Unrelated: pass

def is_parent(val: object) -> TypeIs[Parent]:
    return isinstance(val, Parent)

def run(arg: Child | Unrelated):
    if is_parent(arg):
        # El tipo de ``arg`` es reducido a la intersección
        # de ``Parent`` y ``Child``, lo cual es equivalente a
        # ``Child``.
        assert_type(arg, Child)
    else:
        # El tipo de  ``arg`` es reducido para excluir ``Parent``,
        # para que solo quede ``Unrelated``.
        assert_type(arg, Unrelated)

El tipo dentro de TypeIs debe ser coherente con el tipo del argumento de la función; si no lo es, los comprobadores de tipos estáticos generarán un error. Una función TypeIs escrita incorrectamente puede provocar un comportamiento incorrecto en el sistema de tipos; es responsabilidad del usuario escribir dichas funciones de manera segura.

Si una función TypeIs es un método de clase o instancia, entonces el tipo en TypeIs se asigna al tipo del segundo parámetro (después de cls o self).

En resumen, la forma def foo(arg: TypeA) -> TypeIs[TypeB]: ..., significa que si foo(arg) devuelve True, entonces arg es una instancia de TypeB, y si devuelve False, no es una instancia de TypeB.

TypeIs también funciona con variables de tipo. Para obtener más información, consulte PEP 742 (Restringir tipos con TypeIs).

Added in version 3.13.

typing.TypeGuard¶

Construcción de tipificación especial para marcar funciones de predicado de tipo definido por el usuario.

Las funciones de predicado de tipo son funciones definidas por el usuario que indican si su argumento es una instancia de un tipo en particular. TypeGuard funciona de manera similar a TypeIs, pero tiene efectos ligeramente diferentes en el comportamiento de verificación de tipo (ver a continuació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.

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

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):
        # El tipo de ``val`` es reducido a ``list[str]``.
        print(" ".join(val))
    else:
        # El tipo de ``val`` se mantiene como ``list[object]``.
        print("Not a list of strings!")

TypeIs y TypeGuard se diferencian en los siguientes aspectos:

• TypeIs requiere que el tipo restringido sea un subtipo del tipo de entrada, mientras que TypeGuard no lo requiere. La razón principal es permitir cosas como restringir list[object] a list[str], aunque este último no sea un subtipo del primero, ya que list es invariante.

• Cuando una función TypeGuard devuelve True, los verificadores de tipo limitan el tipo de la variable exactamente al tipo TypeGuard. Cuando una función TypeIs devuelve True, los verificadores de tipo pueden inferir un tipo más preciso combinando el tipo conocido previamente de la variable con el tipo TypeIs. (Técnicamente, esto se conoce como un tipo de intersección).

• Cuando una función TypeGuard devuelve False, los verificadores de tipo no pueden limitar el tipo de la variable en absoluto. Cuando una función TypeIs devuelve False, los verificadores de tipo pueden limitar el tipo de la variable para excluir el tipo TypeIs.

Added in version 3.10.

typing.Unpack¶

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

Por ejemplo, usar el operador de descompresión * en un type variable tuple es equivalente a usar Unpack para marcar la tupla de variable de tipo como descomprimida:

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:

# En versiones anteriores de Python, TypeVarTuple y Unpack
# se encuentran en el paquete de retroadaptación `typing_extensions`.
from typing_extensions import TypeVarTuple, Unpack

Ts = TypeVarTuple('Ts')
tup: tuple[*Ts]         # Error de sintaxis en Python <= 3.10!
tup: tuple[Unpack[Ts]]  # Equivalente semánticamente, y compatible con versiones anteriores

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

# Esta función espera dos argumentos de palabras clave: `name` de tipo `str`
# y `year` de tipo `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, default=typing.NoDefault)¶

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')  # Puede ser cualquier cosa
S = TypeVar('S', bound=str)  # Puede ser cualquier subtipo de str
A = TypeVar('A', str, bytes)  # Tiene que ser exactamente str o 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)  # el tipo revelado es str

class StringSubclass(str):
    pass

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

z = print_capitalized(45)  # error: int no es un subtipo de str

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

# Puede ser cualquier cosa con un método __abs__
def print_abs[T: SupportsAbs](arg: T) -> None:
    print("Absolute value:", abs(arg))

U = TypeVar('U', bound=str|bytes)  # Puede ser cualquier subtipo de la unión str|bytes
V = TypeVar('V', bound=SupportsAbs)  # Puede ser cualquier cosa con un método __abs__

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)  # tipo revelado es str

b = concatenate(StringSubclass('one'), StringSubclass('two'))
reveal_type(b)  # tipo revelado es str, a pesar que se pasa StringSubclass

c = concatenate('one', b'two')  # error: la variable de tipo 'A' puede ser str o bytes en una llamada a función, pero no ambas

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

evaluate_bound()¶

An evaluate function corresponding to the __bound__ attribute. When called directly, this method supports only the VALUE format, which is equivalent to accessing the __bound__ attribute directly, but the method object can be passed to annotationlib.call_evaluate_function() to evaluate the value in a different format.

Added in version 3.14.

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

evaluate_constraints()¶

An evaluate function corresponding to the __constraints__ attribute. When called directly, this method supports only the VALUE format, which is equivalent to accessing the __constraints__ attribute directly, but the method object can be passed to annotationlib.call_evaluate_function() to evaluate the value in a different format.

Added in version 3.14.

__default__¶

El valor predeterminado de la variable de tipo, o typing.NoDefault si no tiene valor predeterminado.

Added in version 3.13.

evaluate_default()¶

An evaluate function corresponding to the __default__ attribute. When called directly, this method supports only the VALUE format, which is equivalent to accessing the __default__ attribute directly, but the method object can be passed to annotationlib.call_evaluate_function() to evaluate the value in a different format.

Added in version 3.14.

has_default()¶

Devuelve si la variable de tipo tiene o no un valor predeterminado. Esto es equivalente a verificar si __default__ no es el singleton typing.NoDefault, excepto que no fuerza la evaluación del valor predeterminado lazily evaluated.

Added in version 3.13.

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.

Distinto en la versión 3.13: Se agregó soporte para valores predeterminados.

class typing.TypeVarTuple(name, *, default=typing.NoDefault)¶

Tupla de variable de tipo. Forma especializada de type variable que habilita genéricos de variadic.

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 está ligado a int, Ts está ligado a ()
# El valor de retorno es (1,), que tiene tipo tuple[int]
move_first_element_to_last(tup=(1,))

# T está ligado a int, Ts está ligado a (str,)
# El valor de retorno es ('spam', 1), que tiene tipo tuple[str, int]
move_first_element_to_last(tup=(1, 'spam'))

# T está ligado a int, Ts está ligado a (str, float)
# El valor de retorno es ('spam', 3.0, 1), que tiene tipo tuple[str, float, int]
move_first_element_to_last(tup=(1, 'spam', 3.0))

# Esto falla al verificar el tipo (y falla en tiempo de ejecución)
# porque tuple[()] no es compatible con tuple[T, *Ts]
# (se requiere al menos un elemento)
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          # No válido
x: tuple[Ts]   # No válido
x: tuple[*Ts]  # La forma correcta de hacerlo

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]:  # Esto está bien
    pass

class Array2[*Shape, DType]:  # Esto también está bien
    pass

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

float_array_1d: Array[float, Height] = Array()     # Totalmente bien
int_array_2d: Array[int, Height, Width] = Array()  # Sip, también está bien

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.

__default__¶

El valor predeterminado de la variable de tipo tupla, o typing.NoDefault si no tiene valor predeterminado.

Added in version 3.13.

evaluate_default()¶

An evaluate function corresponding to the __default__ attribute. When called directly, this method supports only the VALUE format, which is equivalent to accessing the __default__ attribute directly, but the method object can be passed to annotationlib.call_evaluate_function() to evaluate the value in a different format.

Added in version 3.14.

has_default()¶

Devuelve si la variable de tipo tupla tiene o no un valor predeterminado. Esto es equivalente a verificar si __default__ no es el singleton typing.NoDefault, excepto que no fuerza la evaluación del valor predeterminado lazily evaluated.

Added in version 3.13.

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.

Distinto en la versión 3.13: Se agregó soporte para valores predeterminados.

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

Variable de especificación de parámetros. Versión especializada de 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.

__default__¶

El valor predeterminado de la especificación del parámetro, o typing.NoDefault si no tiene valor predeterminado.

Added in version 3.13.

evaluate_default()¶

An evaluate function corresponding to the __default__ attribute. When called directly, this method supports only the VALUE format, which is equivalent to accessing the __default__ attribute directly, but the method object can be passed to annotationlib.call_evaluate_function() to evaluate the value in a different format.

Added in version 3.14.

has_default()¶

Devuelve si la especificación del parámetro tiene o no un valor predeterminado. Esto es equivalente a verificar si __default__ no es el singleton typing.NoDefault, excepto que no fuerza la evaluación del valor predeterminado lazily evaluated.

Added in version 3.13.

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.

Distinto en la versión 3.13: Se agregó soporte para valores predeterminados.

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

The name of the module in which the type alias was defined:

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

evaluate_value()¶

An evaluate function corresponding to the __value__ attribute. When called directly, this method supports only the VALUE format, which is equivalent to accessing the __value__ attribute directly, but the method object can be passed to annotationlib.call_evaluate_function() to evaluate the value in a different format:

>>> type Alias = undefined
>>> Alias.__value__
Traceback (most recent call last):
...
NameError: name 'undefined' is not defined
>>> from annotationlib import Format, call_evaluate_function
>>> Alias.evaluate_value(Format.VALUE)
Traceback (most recent call last):
...
NameError: name 'undefined' is not defined
>>> call_evaluate_function(Alias.evaluate_value, Format.FORWARDREF)
ForwardRef('undefined')

Added in version 3.14.

Unpacking

Type aliases support star unpacking using the *Alias syntax. This is equivalent to using Unpack[Alias] directly:

>>> type Alias = tuple[int, str]
>>> type Unpacked = tuple[bool, *Alias]
>>> Unpacked.__value__
tuple[bool, typing.Unpack[Alias]]

Added in version 3.14.

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:

# Para crear un NamedTuple genérico en Python 3.11
T = TypeVar("T")

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

# También se admite una sintaxis funcional
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.

Distinto en la versión 3.14: Using super() (and the __class__ closure variable) in methods of NamedTuple subclasses is unsupported and causes a TypeError.

Deprecated since version 3.13, will be removed in version 3.15: La sintaxis de argumentos de palabras clave no documentada para crear clases NamedTuple (NT = NamedTuple("NT", x=int)) está obsoleta y no se permitirá en la versión 3.15. En su lugar, utilice la sintaxis basada en clases o la sintaxis funcional.

Deprecated since version 3.13, will be removed in version 3.15: Al utilizar la sintaxis funcional para crear una clase NamedTuple, no se permite pasar un valor al parámetro “campos” (NT = NamedTuple("NT")). También se permite pasar None al parámetro “campos” (NT = NamedTuple("NT", None)). Ambos métodos no estarán permitidos en Python 3.15. Para crear una clase NamedTuple con 0 campos, utilice class NT(NamedTuple): pass o NT = NamedTuple("NT", []).

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)  # Declara el NewType "UserId"
first_user = UserId(1)  # "UserId" retorna el argumento sin cambios en runtime

__module__¶

The name of the module in which the new type is defined.

__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())  # Pasa la verificación de tipos estática

See PEP 544 for more details. Protocol classes decorated with runtime_checkable() (described later) act as simple-minded runtime protocols that check only the presence of given attributes, ignoring their type signatures. Protocol classes without this decorator cannot be used as the second argument to isinstance() or issubclass().

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

Such a protocol can be used with isinstance() and issubclass(). This allows a simple-minded structural check, very similar to «one trick ponies» in collections.abc such as Iterable. For example:

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

This decorator raises TypeError when applied to a non-protocol class.

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: The members of a runtime-checkable protocol are now considered «frozen» at runtime as soon as the class has been created. Monkey-patching attributes onto a runtime-checkable protocol will still work, but will have no impact on isinstance() checks comparing objects to the protocol. See What’s new in Python 3.12 for more details.