typing — Soporte para type hints

Nuevo en la versión 3.5.

Source code: Lib/typing.py

Nota

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

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

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

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

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

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.

For a summary of deprecated features and a deprecation timeline, please see Deprecation Timeline of Major Features.

Ver también

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

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

La documentación en https://typing.readthedocs.io/ es una referencia útil sobre características de sistemas de tipos, herramientas útiles relativas al tipado, y mejores prácticas de tipado.

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. Éstos incluyen:

Alias de tipo

A type alias is defined using the type statement, which creates an instance of TypeAliasType. In this example, Vector and list[float] will be treated equivalently by static type checkers:

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

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

The type statement is new in Python 3.12. For backwards compatibility, type aliases can also be created through simple assignment:

Vector = list[float]

Or marked with TypeAlias to make it explicit that this is a type alias, not a normal variable assignment:

from typing import TypeAlias

Vector: TypeAlias = list[float]

NewType

Utilícese 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 verificador 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

Recall that the use of a type alias declares two types to be equivalent to one another. Doing type Alias = Original will make the static type checker treat Alias as being exactly equivalent to Original in all cases. This is useful when you want to simplify complex type signatures.

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

Nuevo en la versión 3.5.2.

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

Callable

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

Por ejemplo:

from collections.abc import Callable

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

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

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

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

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

Distinto en la versión 3.10: Callable 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

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

from collections.abc import Mapping, Sequence

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

Generics can be parameterized by using type parameter syntax:

from collections.abc import Sequence

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

Or by using the TypeVar factory directly:

from collections.abc import Sequence
from typing import TypeVar

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

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

Distinto en la versión 3.12: Syntactic support for generics is new in Python 3.12.

Tipos genéricos definidos por el usuario

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

from logging import Logger

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

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

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

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

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

Generic classes implicitly inherit from Generic. For compatibility with Python 3.11 and lower, it is also possible to inherit explicitly from Generic to indicate a generic class:

from typing import TypeVar, Generic

T = TypeVar('T')

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

Generic classes have __class_getitem__() methods, meaning they can be parameterised at runtime (e.g. LoggedVar[int] below):

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 en una clase Generic debe ser distinto. Así, no será válido:

from typing import TypeVar, Generic
...

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

T = TypeVar('T')

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

Generic classes can also inherit from other classes:

from collections.abc import Sized

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

When inheriting from generic classes, some type parameters could be fixed:

from collections.abc import Mapping

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

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

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

from collections.abc import Iterable

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

User-defined generic type aliases are also supported. Examples:

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)

For backward compatibility, generic type aliases can also be created through a simple assignment:

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: Syntactic support for generics and type aliases is new in version 3.12. Previously, generic classes had to explicitly inherit from Generic or contain a type variable in one of their bases.

User-defined generics for parameter expressions are also supported via parameter specification variables in the form [**P]. The behavior is consistent with type variables” described above as parameter specification variables are treated by the typing module as a specialized type variable. The one exception to this is that a list of types can be used to substitute a ParamSpec:

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

Classes generic over a ParamSpec can also be created using explicit inheritance from Generic. In this case, ** is not used:

from typing import ParamSpec, Generic

P = ParamSpec('P')

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

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

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

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

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

A user-defined generic class can have ABCs as base classes without a metaclass conflict. Generic metaclasses are not supported. The outcome of parameterizing generics is cached, and most types in the typing module are hashable and comparable for equality.

El tipo Any

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

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

from typing import Any

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

s: str = ''
s = a           # OK

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

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 tal funcionalidad, lo que resulta poco pythónico (idiomático) y poco ajustado a lo que uno normalmente haría en un código Python tipado dinámicamente. Por ejemplo, esto sí se ajusta al PEP 484:

from collections.abc import Sized, Iterable, Iterator

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

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

from collections.abc import Iterator, Iterable

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

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

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

Contenido del módulo

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

Nota

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

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

The deprecated types will be removed from the typing module no sooner than the first Python version released 5 years after the release of Python 3.9.0. See details in PEP 585—Type Hinting Generics In Standard Collections.

Primitivos especiales de tipado

Tipos especiales

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

typing.Any

Tipo especial que indica un tipo sin restricciones.

  • Todos los tipos son compatibles con Any.

  • Any es compatible con todos los tipos.

Distinto en la versión 3.11: Any can now be used as a base class. This can be useful for avoiding type checker errors with classes that can duck type anywhere or are highly dynamic.

typing.AnyStr

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

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

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

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

Tipo especial que solo incluye a las cadenas de texto literales. Una cadena de texto literal es compatible con LiteralString, así como otro LiteralString también lo es, pero un objeto tipado como str no lo es. Una cadena de texto que ha sido creada componiendo objetos tipados como LiteralString también es válida como LiteralString.

Por ejemplo:

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

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

Ésto es util para APIs sensibles donde cadenas de texto arbitrarias generadas por usuarios podrían generar problemas. Por ejemplo, los dos casos que aparecen arriba que generar errores en el verificador de tipos podrían ser vulnerables a un ataque de inyección de SQL.

Véase PEP 675 para más detalle.

Nuevo en la versión 3.11.

typing.Never

El bottom type (tipo vacío), 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

Special type to represent the current enclosed class. For example:

from typing import Self

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

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 actualmente algo sigue el patrón de:

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

Se debiese usar Self, ya que llamadas a SubclassOfFoo.return_self tendrían Foo como valor de retorno, y no 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.

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]

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

Nuevo en la versión 3.10.

Obsoleto desde la versión 3.12: TypeAlias is deprecated in favor of the type statement, which creates instances of TypeAliasType. Note that while TypeAlias and TypeAliasType serve similar purposes and have similar names, they are distinct and the latter is not the type of the former. Removal of TypeAlias is not currently planned, but users are encouraged to migrate to type statements.

Formas especiales

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

typing.Tuple

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

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

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

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

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

Tipo Optional.

Optional[X] es equivalente a X | None (o Union[X, None]).

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

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

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

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

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

typing.Callable

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

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

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

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

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

Ver también

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

typing.Concatenate

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

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

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

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

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

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

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

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

Nuevo en la versión 3.10.

Ver también

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

  • ParamSpec y Callable.

class typing.Type(Generic[CT_co])

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

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

Nótese que Type[C] es covariante:

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

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

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

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

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

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

Nuevo en la versión 3.5.2.

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

typing.Literal

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

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

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

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

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

Nuevo en la versión 3.8.

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

typing.ClassVar

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

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

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

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

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

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

Nuevo en la versión 3.5.3.

typing.Final

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

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

class Connection:
    TIMEOUT: Final[int] = 10

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

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

Nuevo en la versión 3.8.

typing.Required
typing.NotRequired

Constructos de tipado especiales que marcan llaves individuales de un TypedDict como requeridas o no requeridas respectivamente.

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

Nuevo en la versión 3.11.

typing.Annotated

Un tipo introducido en PEP 593 (Anotaciones flexibles de función y variable), para decorar tipos existentes con metadatos específicos del contexto (posiblemente múltiples partes del mismo, ya que Annotated es variádico). En concreto, un tipo T puede ser anotado con el metadato x a través del typehint Annotated[T,x]. Estos metadatos se pueden utilizar para el análisis estático o en tiempo de ejecución. Si una librería (o herramienta) encuentra un typehint Annotated[T,x] y no encuentra una lógica especial para el metadato x, este debería ignorarlo o simplemente tratar el tipo como T. A diferencia de la funcionalidad no_type_check, que actualmente existe en el módulo typing, que deshabilita completamente la comprobación de anotaciones de tipo en una función o clase, el tipo Annotated permite tanto la comprobación de tipos estático de T (la cuál ignoraría x de forma segura) en conjunto con el acceso a x en tiempo de ejecución dentro de una aplicación específica.

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

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

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

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

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

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

Los detalles de la sintaxis:

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

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

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

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

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

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

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

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

  • Anotaciones duplicadas no son removidas:

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

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

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

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

Nuevo en la versión 3.9.

typing.TypeGuard

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

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

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

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

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

  1. El valor de retorno es un booleano.

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

Por ejemplo:

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

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

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

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

Nota

No es necesario que TypeB sea una forma más estrecha de TypeA; incluso puede ser una forma más amplia. La razón principal es permitir cosas como reducir List[object] a List[str] aunque este último no sea un subtipo del primero, ya que List es invariante. La responsabilidad de escribir protecciones de tipo 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

Un operador de tipado que conceptualmente marca en un objeto el hecho de haber sido desempaquetado. Por ejemplo, el uso del operador de desempaquetado * en una type variable tuple es equivalente al uso de Unpack para marcar en una tupla de variables de tipo el haber sido desempaquetada:

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

In fact, Unpack can be used interchangeably with * in the context of typing.TypeVarTuple and builtins.tuple types. You might see Unpack being used explicitly in older versions of Python, where * couldn’t be used in certain places:

# 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 can also be used along with typing.TypedDict for typing **kwargs in a function signature:

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

See PEP 692 for more details on using Unpack for **kwargs typing.

Nuevo en la versión 3.11.

Building generic types and type aliases

The following objects are not used directly in annotations. Instead, they are building blocks for creating generic types and type aliases.

These objects can be created through special syntax (type parameter lists and the type statement). For compatibility with Python 3.11 and earlier, they can also be created without the dedicated syntax, as documented below.

class typing.Generic

Clase base abstracta para tipos genéricos.

A generic type is typically declared by adding a list of type parameters after the class name:

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

Such a class implicitly inherits from Generic. The runtime semantics of this syntax are discussed in the Language Reference.

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

Here the brackets after the function name indicate a generic function.

For backwards compatibility, generic classes can also be declared by explicitly inheriting from Generic. In this case, the type parameters must be declared separately:

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.

The preferred way to construct a type variable is via the dedicated syntax for generic functions, generic classes, and generic type aliases:

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

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

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

However, if desired, reusable type variables can also be constructed manually, like so:

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

Type variables exist primarily for the benefit of static type checkers. They serve as the parameters for generic types as well as for generic function and type alias definitions. See Generic for more information on generic types. Generic functions work as follows:

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.

The variance of type variables is inferred by type checkers when they are created through the type parameter syntax or when infer_variance=True is passed. Manually created type variables may be explicitly marked covariant or contravariant by passing covariant=True or contravariant=True. By default, manually created type variables are invariant. See PEP 484 and PEP 695 for more details.

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

At runtime, isinstance(x, T) will raise TypeError.

__name__

The name of the type variable.

__covariant__

Whether the type var has been explicitly marked as covariant.

__contravariant__

Whether the type var has been explicitly marked as contravariant.

__infer_variance__

Whether the type variable’s variance should be inferred by type checkers.

Nuevo en la versión 3.12.

__bound__

The bound of the type variable, if any.

Distinto en la versión 3.12: For type variables created through type parameter syntax, the bound is evaluated only when the attribute is accessed, not when the type variable is created (see Lazy evaluation).

__constraints__

A tuple containing the constraints of the type variable, if any.

Distinto en la versión 3.12: For type variables created through type parameter syntax, the constraints are evaluated only when the attribute is accessed, not when the type variable is created (see Lazy evaluation).

Distinto en la versión 3.12: Type variables can now be declared using the type parameter syntax introduced by PEP 695. The infer_variance parameter was added.

class typing.TypeVarTuple(name)

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

Type variable tuples can be declared in type parameter lists using a single asterisk (*) before the name:

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

Or by explicitly invoking the TypeVarTuple constructor:

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

Type variable tuples must always be unpacked. This helps distinguish type variable tuples from normal type variables:

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 pueden ser combinadas sin problema con variables de tipo normales:

DType = TypeVar('DType')

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

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

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__

The name of the type variable tuple.

Nuevo en la versión 3.11.

Distinto en la versión 3.12: Type variable tuples can now be declared using the type parameter syntax introduced by 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.

In type parameter lists, parameter specifications can be declared with two asterisks (**):

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

For compatibility with Python 3.11 and earlier, ParamSpec objects can also be created as follows:

P = ParamSpec('P')

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

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

from collections.abc import Callable
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 verificador de tipo no puede verificar la función inner porque *args y **kwargs deben escribirse Any.

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

args
kwargs

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

__name__

The name of the parameter specification.

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: Parameter specifications can now be declared using the type parameter syntax introduced by 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 verificadores de tipo estático.

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

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

Nuevo en la versión 3.10.

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

The type of type aliases created through the type statement.

Por ejemplo:

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

Nuevo en la versión 3.12.

__name__

The name of the type alias:

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

The module in which the type alias was defined:

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

The type parameters of the type alias, or an empty tuple if the alias is not generic:

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

The type alias’s value. This is lazily evaluated, so names used in the definition of the alias are not resolved until the __value__ attribute is accessed:

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

Otras directivas especiales

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

class typing.NamedTuple

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

Uso:

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

Esto es equivalente a:

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

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

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

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

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

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)

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

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

The module in which the new type is defined.

__name__

The name of the new type.

__supertype__

The type that the new type is based on.

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 protocolo. Las clases protocolo se definen así:

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

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

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

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

func(C())  # Passes static type check

Véase PEP 544 para más detalles. Las clases protocolo decoradas con runtime_checkable() (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:
        ...

In code that needs to be compatible with Python 3.11 or older, generic Protocols can be written as follows:

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

Nota

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

Nuevo en la versión 3.8.

Distinto en la versión 3.12: The internal implementation of isinstance() checks against runtime-checkable protocols now uses inspect.getattr_static() to look up attributes (previously, hasattr() was used). As a result, some objects which used to be considered instances of a runtime-checkable protocol may no longer be considered instances of that protocol on Python 3.12+, and vice versa. Most users are unlikely to be affected by this change.

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

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

An alternative way to create a TypedDict is by using function-call syntax. The second argument must be a literal dict:

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

This functional syntax allows defining keys which are not valid identifiers, for example because they are keywords or contain hyphens:

# 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 verificador de tipo admita un False literal o True como valor del argumento total. True es el predeterminado y hace que todos los elementos definidos en el cuerpo de la clase sean obligatorios.

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

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

Un TypedDict puede ser genérico:

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

To create a generic TypedDict that is compatible with Python 3.11 or lower, inherit from Generic explicitly:

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__ entrega 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 retrocompatibilidad con Python 3.10 y versiones más antiguas, es posible utilizar herencia para declarar tanto las llaves requeridas como las no requeridas en el mismo TypedDict. Ésto se logra declarando un TypedDict con un valor para el argumento total y luego heredando de él en otro TypedDict con un valor distinto 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.

Distinto en la versión 3.13: Removed support for the keyword-argument method of creating TypedDicts.

Colecciones genéricas concretas

Correspondientes a tipos integrados

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

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

Este tipo se puede usar de la siguiente manera:

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

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

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

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

Este tipo se puede usar del siguiente modo:

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

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

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

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

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

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

Nota

Tuple es una forma especial.

Correspondiente a tipos en collections

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

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

Nuevo en la versión 3.5.2.

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

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

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

Nuevo en la versión 3.7.2.

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

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

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

Nuevo en la versión 3.5.4.

Nuevo en la versión 3.6.1.

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

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

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

Nuevo en la versión 3.5.4.

Nuevo en la versión 3.6.1.

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

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

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

Nuevo en la versión 3.5.4.

Nuevo en la versión 3.6.1.

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

Otros tipos concretos

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

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

class typing.Pattern
class typing.Match

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

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

class typing.Text

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

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

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

Nuevo en la versión 3.5.2.

Obsoleto desde la versión 3.11: Python 2 is no longer supported, and most type checkers also no longer support type checking Python 2 code. Removal of the alias is not currently planned, but users are encouraged to use str instead of Text.

Clase base abstracta para tipos genéricos

Correspondientes a las colecciones en collections.abc

class typing.AbstractSet(Collection[T_co])

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

Obsoleto desde la versión 3.9: collections.abc.Set 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: Prefer collections.abc.Buffer, or a union like bytes | bytearray | memoryview.

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

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

Nuevo en la versión 3.6.0.

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

class typing.Container(Generic[T_co])

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

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

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

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

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

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

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

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

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

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

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

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

class typing.MappingView(Sized)

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

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

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

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

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

class typing.MutableSequence(Sequence[T])

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

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

class typing.MutableSet(AbstractSet[T])

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

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

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

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

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

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

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

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

Correspondiente a otros tipos en collections.abc

class typing.Iterable(Generic[T_co])

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

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

class typing.Iterator(Iterable[T_co])

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

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

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

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

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

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

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

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

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

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

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

class typing.Hashable

Un alias de collections.abc.Hashable.

Obsoleto desde la versión 3.12: Use collections.abc.Hashable directly instead.

class typing.Reversible(Iterable[T_co])

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

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

class typing.Sized

Un alias de collections.abc.Sized.

Obsoleto desde la versión 3.12: Use collections.abc.Sized directly instead.

Programación asíncrona

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

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

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

Nuevo en la versión 3.5.3.

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

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

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

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

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

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

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

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

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

Nuevo en la versión 3.6.1.

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

class typing.AsyncIterable(Generic[T_co])

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

Nuevo en la versión 3.5.2.

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

class typing.AsyncIterator(AsyncIterable[T_co])

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

Nuevo en la versión 3.5.2.

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

class typing.Awaitable(Generic[T_co])

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

Nuevo en la versión 3.5.2.

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

Tipos del administrador de contextos

class typing.ContextManager(Generic[T_co])

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

Nuevo en la versión 3.5.4.

Nuevo en la versión 3.6.0.

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

class typing.AsyncContextManager(Generic[T_co])

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

Nuevo en la versión 3.5.4.

Nuevo en la versión 3.6.2.

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

Protocolos

Estos protocolos se decoran con runtime_checkable().

class typing.SupportsAbs

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

class typing.SupportsBytes

Una ABC con un método abstracto __bytes__.

class typing.SupportsComplex

Una ABC con un método abstracto __complex__.

class typing.SupportsFloat

Una ABC con un método abstracto __float__.

class typing.SupportsIndex

Una ABC con un método abstracto __index__.

Nuevo en la versión 3.8.

class typing.SupportsInt

Una ABC con un método abstracto __int__.

class typing.SupportsRound

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

Funciones y decoradores

typing.cast(typ, val)

Convertir un valor a 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.

At runtime this does nothing: it returns the first argument unchanged with no checks or side effects, no matter the actual type of the argument.

When a static type checker encounters a call to assert_type(), it emits an error if the value is not of the specified type:

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 será ejecutado, porque arg es un int o un str, y ambas opciones son 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 tipos para arg fuera en cambio int | str | float, el validador de tipos emitiría un error señalando que unreachable es de tipo float. Para que una llamada a assert_never pase la validación de tipos, el tipo inferido del argumento dado debe ser el tipo vacío, 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

Es posible utilizar dataclass_transform para decorar una clase, metaclase, o una función que es ella misma un decorador. La presencia de @dataclass_transform() indica a un validador estático de tipos que el objeto decorado ejecuta, en tiempo de ejecución, «magia» que transforma una clase, dándole comportamientos similares a los que tiene dataclasses.dataclass().

Ejemplo de uso con una función-decorador:

T = TypeVar("T")

@dataclass_transform()
def create_model(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:

  • eq_default indica si, cuando el invocador haya omitido el parámetro eq, el valor de éste debe tomarse por True o False.

  • order_default indica si, cuando el invocador haya omitido el parámetro order, el valor de éste debe tomarse por True o False.

  • kw_only_default indica si, cuando el invocador haya omitido el parámetro kw_only, el valor de éste debe tomarse por True o False.

  • frozen_default indicates whether the frozen parameter is assumed to be True or False if it is omitted by the caller.

    Nuevo en la versión 3.12.

  • field_specifiers (especificadores de campos) especifica una lista estática de clases o funciones soportadas que describen campos, de manera similar a dataclasses.field().

  • Es posible pasar arbitrariamente otros argumentos nombrados para permitir posibles extensiones futuras.

Los validadores de tipos reconocen los siguientes argumentos opcionales en especificadores de campos:

  • init indica si el campo debe ser incluido en el método __init__ sintetizado. Si no es especificado, init será True por defecto.

  • default provee el valor por defecto para el campo.

  • default_factory provee un callback en tiempo de ejecución que retorna el valor por defecto para el campo. Si no se especifican default ni default_factory, se asumirá que el campo no tiene un valor por defecto y que un valor debe ser provisto cuando la clase sea instanciada.

  • factory es un alias para default_factory.

  • kw_only indica si el campo debe ser marcado como exclusivamente de palabra clave. Si es True, el campo será exclusivamente de palabra clave. Si es False no lo será. Si no se especifica, se utilizará el valor para el parámetro kw_only especificado en el objeto decorado con dataclass_transform, o si éste tampoco está especificado, se utilizará el valor de kw_only_default en dataclass_transform.

  • alias provee un nombre alternativo para el campo. Este nombre alternativo será utilizado en el método __init__ sintetizado.

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

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

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

Véase PEP 484 para más detalle y 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)

Retorna una secuencia de definiciones para func decoradas con @overload. func es el objeto función correspondiente a 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) retornará una secuencia de tres objetos función para las tres sobrecargas definidas. Si es llamada con una función que no tenga sobrecargas, get_overloads() retorna 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()

Limpia todas las sobrecargas registradas del registro interno. Ésto puede ser usado para recuperar memoria usada por el registro.

Nuevo en la versión 3.11.

@typing.final

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

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

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

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

Nuevo en la versión 3.8.

Distinto en la versión 3.11: El decorador establecerá a True el atributo __final__ en el objeto decorado. De este modo, es posible utilizar en tiempo de ejecución una verificación como if getattr(obj, "__final__", False) para determinar si un objeto obj has sido marcado como final. Si el objeto decorado no soporta el establecimiento de atributos, el decorador retorna el objeto sin cambios y sin levantar 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 dicha clase (pero no a lo métodos definidos en sus superclases y subclases).

Esto modifica la función o funciones in situ.

@typing.no_type_check_decorator

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

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

@typing.override

A decorator for methods that indicates to type checkers that this method should override a method or attribute with the same name on a base class. This helps prevent bugs that may occur when a base class is changed without an equivalent change to a child class.

Por ejemplo:

class Base:
     def log_status(self)

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

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

There is no runtime checking of this property.

The decorator will set the __override__ attribute to True on the decorated object. Thus, a check like if getattr(obj, "__override__", False) can be used at runtime to determine whether an object obj has been marked as an override. If the decorated object does not support setting attributes, the decorator returns the object unchanged without raising an exception.

See PEP 698 for more details.

Nuevo en la versión 3.12.

@typing.type_check_only

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

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

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

def fetch_response() -> Response: ...

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

Ayudas de introspección

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

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

Habitualmente, esto es lo mismo que obj.__annotations__. Además, las referencias 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 todos los Annotated[T, ...] con T de manera recursiva, a menos que include_extras se defina como True ( véase Annotated para más información). Por ejemplo:

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

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

Nota

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

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

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)

Get the unsubscripted version of a type: for a typing object of the form X[Y, Z, ...] return X. If X is a generic alias for a builtin or collections class, it gets normalized to the original class. If X is an instance of ParamSpecArgs or ParamSpecKwargs, return the underlying ParamSpec. Return None for unsupported objects. Examples:

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)

Get type arguments with all substitutions performed: for a typing object of the form X[Y, Z, ...] return (Y, Z, ...). If X is a union or Literal contained in another generic type, the order of (Y, Z, ...) may be different from the order of the original arguments [Y, Z, ...] due to type caching. Return () for unsupported objects. Examples:

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

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

Nuevo en la versión 3.10.

class typing.ForwardRef

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

Nota

Los tipos genéricos de PEP 585, como list["SomeClass"], no se transformarán implícitamente en list[ForwardRef("SomeClass")] y, por lo tanto, no se resolverán automáticamente en list[SomeClass].

Nuevo en la versión 3.7.4.

Constantes

typing.TYPE_CHECKING

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

if TYPE_CHECKING:
    import expensive_mod

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

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

Nota

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.

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

Versiones typing de colecciones estándares

3.9

No decidido

PEP 585

typing.ByteString

3.9

3.14

gh-91896

typing.Text

3.11

No decidido

gh-92332

typing.Hashable and typing.Sized

3.12

No decidido

gh-94309

typing.TypeAlias

3.12

No decidido

PEP 695