Nota

¡Ayúdanos a traducir la documentación oficial de Python al Español! Puedes encontrar más información en Como contribuir. Ayuda a acercar Python a más personas de habla hispana.

typing — Soporte para type hints

Nuevo en la versión 3.5.

Source code: Lib/typing.py

Nota

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

Este módulo proporciona soporte en tiempo de ejecución para las sugerencias de tipo. Para la especificación original del sistema de tipado, véase PEP 484. Para una introducción simplificada a las sugerencias de tipo, véase PEP 483.

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

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

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

Frecuentemente se agregan nuevas funcionalidades al módulo typing. El paquete typing_extensions provee backports de estas nuevas funcionalidades para versiones más antiguas de Python.

Para ver un resumen de las características descontinuadas y un histórico de estas, consulte Calendario de descontinuación de características principales.

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

”Tipado estático con 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.

PEPs relevantes

Desde la introducción inicial de los indicadores de tipo en PEP 484 y PEP 483, un número de PEPs han modificado y mejorado el sistema de anotaciones de tipos de Python:

The full list of PEPs

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.

Nuevo en la versión 3.5.2.

Distinto en la versión 3.10: NewType es ahora una clase en lugar de una función. Existe un costo de tiempo de ejecución adicional cuando se llama a NewType a través de una función normal.

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

Las funciones – u otro objeto invocable callable se pueden anotar utilizando collections.abc.Callable o typing.Callable. Callable[[int], str] se refiere a una función que toma un solo parámetro de tipo int y retorna un 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 no puede representar firmas complejas como funciones que toman un número variado de argumentos, funciones sobrecargadas o funciones que reciben parámetros de solo palabras clave. Sin embargo, estas firmas se pueden definir al definir una clase Protocol con un método __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

Una variable anotada con C puede aceptar un valor de tipo C. Por el contrario, una variable anotada con type[C] (o typing.Type[C]) puede aceptar valores que sean clases en sí mismas; específicamente, aceptará el objeto de clase de C. Por ejemplo:

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.

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)

Esta sintaxis indica que la clase LoggedVar está parametrizada en torno a una única variable de tipo <TypeVar> T . Esto también hace que T sea válida como tipo dentro del cuerpo de la clase.

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.

Nuevo en la versión 3.11.

typing.Never

El bottom type (tipo vacío), es un tipo que no tiene miembros.

Puede ser utilizado para definir una función que nunca debe ser llamada, o una función que nunca retorna:

from typing import Never

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

Nuevo en la versión 3.11: En versiones antiguas de Python, es posible utilizar NoReturn para expresar el mismo concepto. Se agregó Never para hacer más explicito el significado intencionado .

typing.NoReturn

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

Por ejemplo:

from typing import NoReturn

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

También puede usarse NoReturn como bottom type, un tipo que no tiene valores. Comenzando con Python 3.11, debe usarse, en cambio, el tipo Never para este concepto. Los Validadores de tipo deben tratar a ambos como equivalentes.

Nuevo en la versión 3.5.4.

Nuevo en la versión 3.6.2.

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.

Nuevo en la versión 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.

Nuevo en la versión 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, ParamSpec, TypeVar

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

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

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

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

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

Nuevo en la versión 3.10.

Ver también

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.

Nuevo en la versión 3.8.

Distinto en la versión 3.9.1: Literal ahora elimina los parámetros duplicados. Las comparaciones de igualdad de los objetos Literal ya no dependen del orden. Los objetos Literal ahora lanzarán una excepción TypeError durante las comparaciones de igualdad si uno de sus parámetros no es hashable.

typing.ClassVar

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

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

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

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

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

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

Nuevo en la versión 3.5.3.

typing.Final

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.

Nuevo en la versión 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.

Nuevo en la versión 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.

Nuevo en la versión 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.

La responsabilidad de cómo interpretar los metadatos recae en la herramienta o biblioteca que encuentre la 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)]

Detalles de la sintaxis:

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

  • Se pueden proporcionar varios elementos de metadatos (Annotated admite argumentos variádicos):

    @dataclass
class ctype:
    kind: str

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

    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.

  • Annotated debe estar subscrito con al menos dos argumentos ( Annotated[int] no es válido)

  • El orden de los elementos de metadatos se conserva y es importante para las comprobaciones de igualdad:

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

  • 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]  # NOT valid

    Esto sería equivalente a:

    Annotated[T1, T2, T3, ..., Ann1]

    donde T1, T2, etc. son TypeVars. Esto no sería válido: solo se debe pasar un tipo a 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')

Ver también

PEP 593 - Anotaciones flexibles de funciones y variables

El PEP introduce Annotated en la biblioteca estándar.

Nuevo en la versión 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!")

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

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

Nota

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

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

Nuevo en la versión 3.10.

typing.Unpack

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

Por ejemplo, usar el operador de desempaquetamiento * en una tupla de variable de tipo es equivalente a usar Unpack para marcar la tupla de variable de tipo como desempaquetada:

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.

Nuevo en la versión 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
    ...

Esta sintaxis también se puede utilizar para crear variables de tipo enlazadas y restringidas:

class StrSequence[S: str]:  # S is a TypeVar bound to 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

Nótese que las variables de tipo pueden ser bound (delimitadas), constrained (restringidas), o ninguna, pero no pueden ser al mismo tiempo delimitadas y restringidas.

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.

Las variables de tipo delimitadas y las variables de tipo restringidas tienen semánticas distintas en varios aspectos importantes. Usar una variable de tipo bound (delimitada) significa que la TypeVar será resuelta utilizando el tipo más específico posible:

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

Las variables de tipo pueden estar delimitadas por tipos concretos, tipos abstractos (ABCs o protocols) e incluso uniones de tipos:

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

Nuevo en la versión 3.12.

__bound__

El límite de la variable de tipo, si existe.

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)

Tupla de variables de tipo. Una versión especializada de type variables que permite genéricos variádicos.

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.

Nuevo en la versión 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)

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

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

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

Nuevo en la versión 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

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
>>> P = ParamSpec("P")
>>> get_origin(P.args) is P
True
>>> get_origin(P.kwargs) is P
True

Nuevo en la versión 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'>

Nuevo en la versión 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 or lower
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.

Nuevo en la versión 3.5.2.

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

class typing.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:
        ...

Nuevo en la versión 3.8.

@typing.runtime_checkable

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

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

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

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

@runtime_checkable
class Named(Protocol):
    name: str

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

Nota

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

Nuevo en la versión 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)

Obsoleto desde la versión 3.11, se eliminará en la versión 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.

También es preferible el uso de la sintaxis funcional cuando cualquiera de las llaves no sean identifiers válidos, por ejemplo porque son palabras clave o contienen guiones. Ejemplo:

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

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

De forma predeterminada, todas las 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
__required_keys__

Nuevo en la versión 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

Nuevo en la versión 3.9.

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

Nuevo en la versión 3.8.

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

Nuevo en la versión 3.8.

class typing.SupportsInt

Una ABC con un método abstracto __int__.

class typing.SupportsRound

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

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)

Nuevo en la versión 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 contiene más información acerca de la verificación de exhaustividad con tipado estático.

Nuevo en la versión 3.11.

typing.reveal_type(obj, /)

Revela el tipo estático inferido de una expresión.

Cuando un validador estático de tipos se encuentra con una invocación a esta función, emite un diagnostico con el tipo del argumento. Por ejemplo:

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.

Esta función retorna su argumento sin cambios, lo que permite su uso dentro de una expresión:

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

La mayoría de los validadores de tipos soportan reveal_type() en cualquier lugar, incluso si el nombre no ha sido importado desde typing. Importar el nombre desde typing permite que el código corra sin errores en tiempo de ejecución y comunica la intención de forma más clara.

En tiempo de ejecución, esta función imprime al stderr el tipo en tiempo de ejecución de su argumento y lo retorna in cambios:

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

Nuevo en la versión 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.

Nuevo en la versión 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.

Nuevo en la versión 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.

Nuevo en la versión 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.

Nuevo en la versión 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.

Nuevo en la versión 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.

Habitualmente, esto es lo mismo que obj.__annotations__. Además, las referencias hacia adelante codificadas como literales de texto se manejan evaluándolas en los espacios de nombres globals y locals. Para una clase C, se retorna un diccionario construido por la combinación de __annotations__ y C.__mro en orden inverso.

La función reemplaza recursivamente todos los Annotated[T, ...] con T, a menos que include_extras esté configurado como True (consulte Annotated para obtener más información). Por ejemplo:

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

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

Nota

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

Distinto en la versión 3.9: Se 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
P = ParamSpec('P')
assert get_origin(P.args) is P
assert get_origin(P.kwargs) is P

Nuevo en la versión 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)

Nuevo en la versión 3.8.

typing.is_typeddict(tp)

Compruebe si un tipo es TypedDict.

Por ejemplo:

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

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)

Nuevo en la versión 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].

Nuevo en la versión 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).

Nuevo en la versión 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.

Tenga en cuenta que para anotar argumentos, es preferible utilizar un tipo de colección abstracto como Mapping en lugar de utilizar dict o typing.Dict.

Este tipo se puede usar de la siguiente manera:

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

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

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

Alias obsoleto de list.

Tenga en cuenta que para anotar argumentos, es preferible utilizar un tipo de colección abstracto como Sequence o Iterable en lugar de utilizar list o typing.List.

Este tipo se puede usar del siguiente modo:

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

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

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

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

Alias obsoleto de builtins.set.

Tenga en cuenta que para anotar argumentos, es preferible utilizar un tipo de colección abstracto como AbstractSet en lugar de utilizar set o 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.

Nuevo en la versión 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.

Nuevo en la versión 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.

Nuevo en la versión 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.

Nuevo en la versión 3.5.4.

Nuevo en la versión 3.6.1.

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

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

Alias obsoleto de collections.Counter.

Nuevo en la versión 3.5.4.

Nuevo en la versión 3.6.1.

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

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

Alias obsoleto de collections.deque.

Nuevo en la versión 3.5.4.

Nuevo en la versión 3.6.1.

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

Alias ​​a otros tipos concretos

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

class typing.Pattern
class typing.Match

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

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

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

class typing.Text

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'

Nuevo en la versión 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.

Obsoleto desde la versión 3.9, se eliminará en la versión 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.

Nuevo en la versión 3.6.0.

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.

Este tipo se puede usar de la siguiente manera:

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

Obsoleto desde la versión 3.9: collections.abc.Mapping ahora soporta 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.

La variación y el orden de las variables de tipo corresponden a las de Generator, por ejemplo:

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

Nuevo en la versión 3.5.3.

Obsoleto desde la versión 3.9: collections.abc.Coroutine ahora soporta 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.

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

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

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

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

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

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

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

Nuevo en la versión 3.6.1.

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

class typing.AsyncIterable(Generic[T_co])

Alias obsoleto de collections.abc.AsyncIterable.

Nuevo en la versión 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.

Nuevo en la versión 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.

Nuevo en la versión 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.

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

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

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

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

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

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

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

Obsoleto desde la versión 3.9: collections.abc.Generator ahora soporta 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.

Nuevo en la versión 3.5.4.

Nuevo en la versión 3.6.0.

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

class typing.AsyncContextManager(Generic[T_co])

Alias obsoleto de contextlib.AbstractAsyncContextManager.

Nuevo en la versión 3.5.4.

Nuevo en la versión 3.6.2.

Obsoleto desde la versión 3.9: contextlib.AbstractAsyncContextManager ahora soporta 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 typing.re

3.8

3.13

bpo-38291

Versiones typing de colecciones estándares

3.9

No decidido (ver Alias obsoletos para más información)

PEP 585

typing.ByteString

3.9

3.14

gh-91896

typing.Text

3.11

No decidido

gh-92332

typing.Hashable y typing.Sized

3.12

No decidido

gh-94309

typing.TypeAlias

3.12

No decidido

PEP 695