Nota
¡Ayúdanos a traducir la documentación oficial de Python al Español! Puedes encontrar más información en Como contribuir. Ayuda a acercar Python a más personas de habla hispana.
typing
— Soporte para type hints¶
Nuevo en la versión 3.5.
Source code: Lib/typing.py
Nota
En tiempo de ejecución, Python no impone las anotaciones de tipado en funciones y variables. Pueden ser utilizadas por herramientas de terceros como validadores de tipado, IDEs, linters, etc.
Este módulo entrega soporte en tiempo de ejecución para indicadores de tipo. El soporte fundamental se encuentra en los tipos Any
, Union
, Callable
, TypeVar
, y Generic
. Para una especificación completa, por favor ver PEP 484. Para una introducción simplificada a los indicadores de tipo, véase PEP 483.
La siguiente función toma y retorna una cadena de texto, que se anota de la siguiente manera:
def greeting(name: str) -> str:
return 'Hello ' + name
En la función greeting
, se espera que el argumento name
sea de tipo str
y que el tipo retornado sea str
. Los subtipos también son aceptados como argumento válido.
Frecuentemente se agregan nuevas funcionalidades al módulo typing
. El paquete typing_extensions provee backports de estas nuevas funcionalidades para versiones más antiguas de Python.
For a summary of deprecated features and a deprecation timeline, please see Deprecation Timeline of Major Features.
Ver también
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:
- PEP 544: Protocolos: herencia estructural («duck typing» estático)
Introduce
Protocol
y el decorador@runtime_checkable
- PEP 585: Indicadores de tipo genéricos en las colecciones estándar
Introduce
types.GenericAlias
y la habilidad de utilizar clases de la librería estándar como tipos genéricos
- PEP 604: Permitir la escritura de tipos unión como
X | Y
Introduce
types.UnionType
y la habilidad de usar el operador binario de disyunción|
para significar una unión de tipos
- PEP 604: Permitir la escritura de tipos unión como
- PEP 612: Variables de especificación de parámetros
Introduce
ParamSpec
yConcatenate
- PEP 646: Genéricos variádicos
Introduce
TypeVarTuple
- PEP 655: Marcar elementos individuales de un TypedDict como requeridos o potencialmente ausentes
Introduce
Required
yNotRequired
- PEP 675: Tipo para cadenas de caracteres literales arbitrarias
Introduce
LiteralString
- PEP 681: Data Class Transforms
Introduce el decorador
@dataclass_transform
Alias de tipo¶
Un alias de tipo se define asignando el tipo al alias. En este ejemplo, Vector
y List[float]
serán tratados como sinónimos intercambiables:
Vector = list[float]
def scale(scalar: float, vector: Vector) -> Vector:
return [scalar * num for num in vector]
# passes type checking; a list of floats qualifies as a Vector.
new_vector = scale(2.0, [1.0, -4.2, 5.4])
Los alias de tipo son útiles para simplificar firmas de tipo complejas. Por ejemplo:
from collections.abc import Sequence
ConnectionOptions = dict[str, str]
Address = tuple[str, int]
Server = tuple[Address, ConnectionOptions]
def broadcast_message(message: str, servers: Sequence[Server]) -> None:
...
# The static type checker will treat the previous type signature as
# being exactly equivalent to this one.
def broadcast_message(
message: str,
servers: Sequence[tuple[tuple[str, int], dict[str, str]]]) -> None:
...
Nótese que None
como indicador de tipo es un caso especial y es substituido por type(None)
.
NewType¶
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
Recuérdese que el uso de alias de tipo implica que los dos tipos son equivalentes entre sí. Haciendo Alias = Original
provocará que el Validador estático de tipos trate Alias
como algo exactamente equivalente a Original
en todos los casos. Esto es útil para cuando se quiera simplificar indicadores de tipo complejos.
En cambio, NewType
declara un tipo que es subtipo de otro. Haciendo Derived = NewType('Derived', Original)
hará que el Validador estático de tipos trate Derived
como una subclase de Original
, lo que implica que un valor de tipo Original
no puede ser usado allí donde se espere un valor de tipo Derived
. Esto es útil para prevenir errores lógicos con un coste de ejecución mínimo.
Nuevo en la versión 3.5.2.
Distinto en la versión 3.10: NewType
es ahora una clase en lugar de una función. Existe un costo de tiempo de ejecución adicional cuando se llama a NewType
a través de una función normal. Sin embargo, este costo se reducirá en 3.11.0.
Callable¶
Entidades que esperen llamadas a funciones con interfaces específicas puede ser anotadas usando Callable[[Arg1Type, Arg2Type], ReturnType]
.
Por ejemplo:
from collections.abc import Callable
def feeder(get_next_item: Callable[[], str]) -> None:
# Body
def async_query(on_success: Callable[[int], None],
on_error: Callable[[int, Exception], None]) -> None:
# Body
async def on_update(value: str) -> None:
# Body
callback: Callable[[str], Awaitable[None]] = on_update
Es posible declarar el tipo de retorno de un callable (invocable) sin especificar tipos en los parámetros substituyendo la lista de argumentos por unos puntos suspensivos (…) en el indicador de tipo: Callable[..., ReturnType]
.
Los invocables que toman otros invocables como argumentos pueden indicar que sus tipos de parámetros dependen unos de otros utilizando ParamSpec
. Además, si ese invocable agrega o elimina argumentos de otros invocables, se puede utilizar el operador Concatenate
. Toman la forma Callable[ParamSpecVariable, ReturnType]
y Callable[Concatenate[Arg1Type, Arg2Type, ..., ParamSpecVariable], ReturnType]
respectivamente.
Distinto en la versión 3.10: Callable
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: ...
Los genéricos se pueden parametrizar usando una nueva factory disponible en typing llamada TypeVar
.
from collections.abc import Sequence
from typing import TypeVar
T = TypeVar('T') # Declare type variable
def first(l: Sequence[T]) -> T: # Generic function
return l[0]
Tipos genéricos definidos por el usuario¶
Una clase definida por el usuario puede ser definida como una clase genérica.
from typing import TypeVar, Generic
from logging import Logger
T = TypeVar('T')
class LoggedVar(Generic[T]):
def __init__(self, value: T, name: str, logger: Logger) -> None:
self.name = name
self.logger = logger
self.value = value
def set(self, new: T) -> None:
self.log('Set ' + repr(self.value))
self.value = new
def get(self) -> T:
self.log('Get ' + repr(self.value))
return self.value
def log(self, message: str) -> None:
self.logger.info('%s: %s', self.name, message)
Generic[T]
como clase base define que la clase LoggedVar
toma un solo parámetro T
. Esto también implica que T
es un tipo válido dentro del cuerpo de la clase.
La clase base Generic
define __class_getitem__()
para que LoggedVar[T]
sea válido como tipo:
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
T = TypeVar('T', contravariant=True)
B = TypeVar('B', bound=Sequence[bytes], covariant=True)
S = TypeVar('S', int, str)
class WeirdTrio(Generic[T, B, S]):
...
Cada argumento de variable de tipo en una clase Generic
debe ser distinto. Así, no será válido:
from typing import TypeVar, Generic
...
T = TypeVar('T')
class Pair(Generic[T, T]): # INVALID
...
Se puede utilizar herencia múltiple con Generic
:
from collections.abc import Sized
from typing import TypeVar, Generic
T = TypeVar('T')
class LinkedList(Sized, Generic[T]):
...
Cuando se hereda de clases genéricas, se pueden fijar algunas variables de tipo:
from collections.abc import Mapping
from typing import TypeVar
T = TypeVar('T')
class MyDict(Mapping[str, T]):
...
En este caso MyDict
tiene un solo parámetro, T
.
Al usar una clase genérica sin especificar parámetros de tipo se asume Any
para todas las posiciones. En el siguiente ejemplo, MyIterable
no es genérico pero hereda implícitamente de Iterable[Any]
:
from collections.abc import Iterable
class MyIterable(Iterable): # Same as Iterable[Any]
Son posibles los alias de tipos genéricos definidos por el usuario. Ejemplos:
from collections.abc import Iterable
from typing import TypeVar
S = TypeVar('S')
Response = Iterable[S] | int
# Return type here is same as Iterable[str] | int
def response(query: str) -> Response[str]:
...
T = TypeVar('T', int, float, complex)
Vec = Iterable[tuple[T, T]]
def inproduct(v: Vec[T]) -> T: # Same as Iterable[tuple[T, T]]
return sum(x*y for x, y in v)
Distinto en la versión 3.7: Generic
ya no posee una metaclase personalizable.
Los genéricos definidos por el usuario para expresiones de parámetros también se admiten a través de variables de especificación de parámetros con el formato Generic[P]
. El comportamiento es coherente con las variables de tipo descritas anteriormente, ya que el módulo typing trata las variables de especificación de parámetros como una variable de tipo especializada. La única excepción a esto es que se puede usar una lista de tipos para sustituir un ParamSpec
:
>>> from typing import Generic, ParamSpec, TypeVar
>>> T = TypeVar('T')
>>> P = ParamSpec('P')
>>> class Z(Generic[T, P]): ...
...
>>> Z[int, [dict, float]]
__main__.Z[int, (<class 'dict'>, <class 'float'>)]
Además, un genérico con una sola variable de especificación de parámetro aceptará listas de parámetros en los formatos X[[Type1, Type2, ...]]
y también X[Type1, Type2, ...]
por razones estéticas. Internamente, este último se convierte en el primero y, por lo tanto, son equivalentes:
>>> class X(Generic[P]): ...
...
>>> X[int, str]
__main__.X[(<class 'int'>, <class 'str'>)]
>>> X[[int, str]]
__main__.X[(<class 'int'>, <class '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.
Un clase genérica definida por el usuario puede tener clases ABC como clase base sin conflicto de metaclase. Las metaclases genéricas no están permitidas. El resultado de parametrizar clases genéricas se cachea, y la mayoría de los tipos en el módulo typing pueden tener un hash y ser comparables por igualdad (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.
Los tipos obsoletos serán removidos del módulo Generic
en la primera versión de Python que sea lanzada 5 años después del lanzamiento de Python 3.9.0. Véase los detalles en PEP 585 – Sugerencias de tipo genéricas en las Colecciones Estándar.
Primitivos especiales de tipado¶
Tipos especiales¶
Estos pueden ser usados como tipos en anotaciones y no soportan []
.
- typing.Any¶
Tipo especial que indica un tipo sin restricciones.
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.LiteralString¶
Tipo especial que solo incluye a las cadenas de texto literales. Una cadena de texto literal es compatible con
LiteralString
, así como otroLiteralString
también lo es, pero un objeto tipado comostr
no lo es. Una cadena de texto que ha sido creada componiendo objetos tipados comoLiteralString
también es válida comoLiteralString
.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 tipoNever
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 aSubclassOfFoo.return_self
tendríanFoo
como valor de retorno, y noSubclassOfFoo
.Otros casos de uso comunes incluyen:
classmethod
usados como constructores alternativos y retornan instancias del parámetrocls
.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.
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 simpleTuple
es equivalente aTuple[Any, ...]
y, a su vez, atuple
.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 aX | Y
y significa X o Y.Para definir una unión, use p. ej.
Union[int, str]
o la abreviaturaint | 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 aX | None
(oUnion[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 deOptional
, 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 retornaReturnType
. Un simpleCallable
es equivalente aCallable[..., Any]
y, a su vez, acollections.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 operadorConcatenate
. Toman la formaCallable[ParamSpecVariable, ReturnType]
yCallable[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 conParamSpec
yConcatenate
. Consulte PEP 612 para obtener más información.Ver también
La documentación de
ParamSpec
yConcatenate
proporciona ejemplos de uso conCallable
.
- typing.Concatenate¶
Se utiliza con
Callable
yParamSpec
para escribir anotar un invocable de orden superior que agrega, elimina o transforma parámetros de otro invocable. El uso tiene el formatoConcatenate[Arg1Type, Arg2Type, ..., ParamSpecVariable]
. Actualmente,Concatenate
solo es válido cuando se utiliza como primer argumento de unCallable
. El último parámetro deConcatenate
debe ser unParamSpec
o unos puntos suspensivos (...
).Por ejemplo, para anotar un decorador
with_lock
que proporciona unthreading.Lock
a la función decorada,Concatenate
puede usarse para indicar quewith_lock
espera un invocable que toma unLock
como primer argumento y retorna un invocable con un tipo de firma diferente. En este caso, elParamSpec
indica que los tipos de parámetros de los invocables retornados dependen de los tipos de parámetros de los invocables que se pasan enfrom 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
- class typing.Type(Generic[CT_co])¶
Una variable indicada como
C
puede aceptar valores de tipoC
. Sin embargo, un variable indicada comoType[C]
puede aceptar valores que son clases en sí mismas – específicamente, aceptará el objeto clase deC
. 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 deC
deben implementar la misma interfaz del constructor y las mismas interfaces de los métodos de clase queC
. 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 aType
, que a su vez es equivalente atype
, 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 deLiteral[...]
, 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.
- 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 conisinstance()
oissubclass()
.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 queAnnotated
es variádico). En concreto, un tipoT
puede ser anotado con el metadatox
a través del typehintAnnotated[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 typehintAnnotated[T,x]
y no encuentra una lógica especial para el metadatox
, este debería ignorarlo o simplemente tratar el tipo comoT
. A diferencia de la funcionalidadno_type_check
, que actualmente existe en el módulotyping
, que deshabilita completamente la comprobación de anotaciones de tipo en una función o clase, el tipoAnnotated
permite tanto la comprobación de tipos estático deT
(la cuál ignoraríax
de forma segura) en conjunto con el acceso ax
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 tipoAnnotated
puede escanear las anotaciones para determinar si son de interés. (por ejemplo, usandoisinstance()
).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
aget_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álidoSe 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:El valor de retorno es un booleano.
Si el valor de retorno es
True
, el tipo de su argumento es el tipo dentro deTypeGuard
.
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 enTypeGuard
se asigna al tipo del segundo parámetro después decls
oself
.En resumen, la forma
def foo(arg: TypeA) -> TypeGuard[TypeB]: ...
significa que sifoo(arg)
retornaTrue
, entoncesarg
se estrecha deTypeA
aTypeB
.Nota
No es necesario que
TypeB
sea una forma más estrecha deTypeA
; incluso puede ser una forma más amplia. La razón principal es permitir cosas como reducirList[object]
aList[str]
aunque este último no sea un subtipo del primero, ya queList
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.
Construir tipos genéricos¶
Estos no son utilizados en anotaciones. Son utilizados como bloques para crear tipos genéricos.
- class typing.Generic¶
Clase base abstracta para tipos genéricos.
Un tipo genérico se declara habitualmente heredando de una instancia de esta clase con una o más variables de tipo. Por ejemplo, un tipo de mapeo genérico se podría definir como:
class Mapping(Generic[KT, VT]): def __getitem__(self, key: KT) -> VT: ... # Etc.
Entonces, esta clase se puede usar como sigue:
X = TypeVar('X') Y = TypeVar('Y') def lookup_name(mapping: Mapping[X, Y], key: X, default: Y) -> Y: try: return mapping[key] except KeyError: return default
- class typing.TypeVar¶
Variable de tipo.
Uso:
T = TypeVar('T') # Can be anything S = TypeVar('S', bound=str) # Can be any subtype of str A = TypeVar('A', str, bytes) # Must be exactly str or bytes
Las variables de tipo son principalmente para ayudar a los validadores estáticos de tipos. Sirven tanto como de parámetros para tipos genéricos como para definición de funciones genéricas. Véase
Generic
para más información sobre tipos genéricos. Las funciones genéricas funcionan de la siguiente manera:def repeat(x: T, n: int) -> Sequence[T]: """Return a list containing n references to x.""" return [x]*n def print_capitalized(x: S) -> S: """Print x capitalized, and return x.""" print(x.capitalize()) return x def concatenate(x: A, y: A) -> A: """Add two strings or bytes objects together.""" return x + y
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.
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:
U = TypeVar('U', bound=str|bytes) # Can be any subtype of the union str|bytes V = TypeVar('V', bound=SupportsAbs) # Can be anything with an __abs__ method
Sin embargo, usar una variable de tipo constrained significa que la
TypeVar
sólo podrá ser determinada como exactamente una de las restricciones dadas:a = concatenate('one', 'two') reveal_type(a) # revealed type is str b = concatenate(StringSubclass('one'), StringSubclass('two')) reveal_type(b) # revealed type is str, despite StringSubclass being passed in c = concatenate('one', b'two') # error: type variable 'A' can be either str or bytes in a function call, but not both
En tiempo de ejecución,
isinstance(x, T)
lanzará una excepciónTypeError
. En general,isinstance()
yissubclass()
no se deben usar con variables de tipo.Las variables de tipo pueden ser marcadas como covariantes o contravariantes pasando
covariant=True
ocontravariant=True
, respectivamente. Véase PEP 484 para más detalles. Por defecto, las variables de tipo son invariantes.
- class typing.TypeVarTuple¶
Tupla de variables de tipo. Una versión especializada de
type variables
que permite genéricos variádicos.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 = TypeVar('T') Ts = TypeVarTuple('Ts') def move_first_element_to_last(tup: tuple[T, *Ts]) -> tuple[*Ts, T]: return (*tup[1:], tup[0]) # 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
*
entuple[T, *Ts]
. Conceptualmente, puede pensarse enTs
como una tupla de variables de tipo(T1, T2, ...)
.tuple[T, *Ts]
se convertiría entuple[T, *(T1, T2, ...)]
, lo que es equivalente atuple[T, T1, T2, ...]
. (Nótese que en versiones más antiguas de Python, ésto puede verse escrito usando en cambioUnpack
, en la formaUnpack[Ts]
.)Las tuplas de variables de tipo siempre deben ser desempaquetadas. Esto ayuda a distinguir tuplas de variables de tipos, de variables de tipo normales:
x: Ts # Not valid x: tuple[Ts] # Not valid x: tuple[*Ts] # The correct way to 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:
Shape = TypeVarTuple('Shape') class Array(Generic[*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(Generic[DType, *Shape]): # This is fine pass class Array2(Generic[*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(Generic[*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( 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 sonint
-*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 acall_soon
calcen con los tipos de los argumentos (posicionales) decallback
.Véase PEP 646 para obtener más detalles sobre las tuplas de variables de tipo.
Nuevo en la versión 3.11.
- 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 unatype variable tuple
es equivalente al uso deUnpack
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]]
De hecho, es posible utilizar
Unpack
indistintamente de*
en el contexto de tipos.Unpack
puede ser visto siendo usado explícitamente en versiones más antiguas de Python, donde*
no podía ser usado en ciertos lugares:# In older versions of Python, TypeVarTuple and Unpack # are located in the `typing_extensions` backports package. from typing_extensions import TypeVarTuple, Unpack Ts = TypeVarTuple('Ts') tup: tuple[*Ts] # Syntax error on Python <= 3.10! tup: tuple[Unpack[Ts]] # Semantically equivalent, and backwards-compatible
Nuevo en la versión 3.11.
- class typing.ParamSpec(name, *, bound=None, covariant=False, contravariant=False)¶
Variable de especificación de parámetros. Una versión especializada de
type variables
.Uso:
P = ParamSpec('P')
Las variables de especificación de parámetros existen principalmente para el beneficio de los verificadores de tipo estático. Se utilizan para reenviar los tipos de parámetros de un invocable a otro invocable, un patrón que se encuentra comúnmente en funciones y decoradores de orden superior. Solo son válidos cuando se utilizan en
Concatenate
, o como primer argumento deCallable
, o como parámetros para genéricos definidos por el usuario. ConsulteGeneric
para obtener más información sobre tipos genéricos.Por ejemplo, para agregar un registro básico a una función, se puede crear un decorador
add_logging
para registrar llamadas a funciones. La variable de especificación de parámetros le dice al verificador de tipo que el invocable pasado al decorador y el nuevo invocable retornado por él tienen parámetros de tipo interdependientes:from collections.abc import Callable from typing import TypeVar, ParamSpec import logging T = TypeVar('T') P = ParamSpec('P') def add_logging(f: Callable[P, T]) -> Callable[P, T]: '''A type-safe decorator to add logging to a function.''' def inner(*args: P.args, **kwargs: P.kwargs) -> T: logging.info(f'{f.__name__} was called') return f(*args, **kwargs) return inner @add_logging def add_two(x: float, y: float) -> float: '''Add two numbers together.''' return x + y
Sin
ParamSpec
, la forma más sencilla de anotar esto anteriormente era usar unTypeVar
conCallable[..., Any]
enlazado. Sin embargo, esto causa dos problemas:El verificador de tipo no puede verificar la función
inner
porque*args
y**kwargs
deben escribirseAny
.Es posible que se requiera
cast()
en el cuerpo del decoradoradd_logging
al retornar la funcióninner
, o se debe indicar al verificador de tipo estático que ignore elreturn inner
.
- args¶
- kwargs¶
Dado que
ParamSpec
captura tanto parámetros posicionales como de palabras clave,P.args
yP.kwargs
se pueden utilizar para dividir unParamSpec
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
yP.kwargs
son instancias respectivamente deParamSpecArgs
yParamSpecKwargs
.
Las variables de especificación de parámetros creadas con
covariant=True
ocontravariant=True
se pueden utilizar para declarar tipos genéricos covariantes o contravariantes. También se acepta el argumentobound
, similar aTypeVar
. Sin embargo, la semántica real de estas palabras clave aún no se ha decidido.Nuevo en la versión 3.10.
Nota
Solo las variables de especificación de parámetros definidas en el ámbito global pueden ser serializadas.
Ver también
PEP 612 - Variables de especificación de parámetros (el PEP que introdujo
ParamSpec
yConcatenate
).
- typing.ParamSpecArgs¶
- typing.ParamSpecKwargs¶
Argumentos y atributos de argumentos de palabras clave de un
ParamSpec
. El atributoP.args
de unParamSpec
es una instancia deParamSpecArgs
yP.kwargs
es una instancia deParamSpecKwargs
. 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á elParamSpec
original:P = ParamSpec("P") get_origin(P.args) # returns P get_origin(P.kwargs) # returns P
Nuevo en la versión 3.10.
- typing.AnyStr¶
AnyStr
es unaconstrained type variable
definida comoAnyStr = TypeVar('AnyStr', str, bytes)
.Su objetivo es ser usada por funciones que pueden aceptar cualquier tipo de cadena de texto sin permitir mezclar diferentes tipos al mismo tiempo. Por ejemplo:
def concat(a: AnyStr, b: AnyStr) -> AnyStr: return a + b concat(u"foo", u"bar") # Ok, output has type 'unicode' concat(b"foo", b"bar") # Ok, output has type 'bytes' concat(u"foo", b"bar") # Error, cannot mix unicode and bytes
- class typing.Protocol(Generic)¶
Clase base para clases protocolo. Las clases protocolo se definen así:
class Proto(Protocol): def meth(self) -> int: ...
Tales clases son usadas principalmente con validadores estáticos de tipos que detectan subtipado estructural (duck-typing estático), por ejemplo:
class C: def meth(self) -> int: return 0 def func(x: Proto) -> int: return x.meth() func(C()) # Passes static type check
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(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()
yissubclass()
. Esto lanzará una excepciónTypeError
cuando se aplique a una clase que no es un protocolo. Esto permite una comprobación estructural simple, muy semejante a «one trick ponies» encollections.abc
conIterable
. Por ejemplo:@runtime_checkable class Closable(Protocol): def close(self): ... assert isinstance(open('/some/file'), Closable)
Nota
runtime_checkable()
verificará solo la presencia de los métodos requeridos, no sus firmas de tipo. Por ejemplo,ssl.SSLObject
es una clase, por lo que pasa una verificaciónissubclass()
contraCallable
. Sin embargo, el métodossl.SSLObject.__init__()
existe solo para lanzar unTypeError
con un mensaje más informativo, por lo que es imposible llamar (instanciar)ssl.SSLObject
.Nuevo en la versión 3.8.
Otras directivas especiales¶
Estos no son utilizados en anotaciones. Son utilizados como bloques para crear tipos genéricos.
- class typing.NamedTuple¶
Versión para anotación de tipos de
collections.namedtuple()
.Uso:
class Employee(NamedTuple): name: str id: int
Esto es equivalente a:
Employee = collections.namedtuple('Employee', ['name', 'id'])
Para proporcionar a un campo un valor por defecto se puede asignar en el cuerpo de la clase:
class Employee(NamedTuple): name: str id: int = 3 employee = Employee('Guido') assert employee.id == 3
Los campos con un valor por defecto deben ir después de los campos sin valor por defecto.
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 APInamedtuple()
.)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(NamedTuple, Generic[T]): key: T group: list[T]
Uso retrocompatible:
Employee = NamedTuple('Employee', [('name', str), ('id', int)])
Distinto en la versión 3.6: Soporte añadido para la sintaxis de anotación de variables propuesto en PEP 526.
Distinto en la versión 3.6.1: Soporte añadido para valores por defecto, métodos y docstrings.
Distinto en la versión 3.8: Los atributos
_field_types
y__annotations__
son simples diccionarios en vez de instancias deOrderedDict
.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)
Nuevo en la versión 3.5.2.
Distinto en la versión 3.10:
NewType
es ahora una clase en lugar de una función.
- class typing.TypedDict(dict)¶
Es una construcción especial para añadir indicadores de tipo a un diccionario. En tiempo de ejecución es un
dict
simple.TypedDict
crea un tipo de diccionario que espera que todas sus instancias tenga un cierto conjunto de claves, donde cada clave está asociada con un valor de un tipo determinado. Esta exigencia no se comprueba en tiempo de ejecución y solo es aplicada por validadores de tipo. Uso:class Point2D(TypedDict): x: int y: int label: str a: Point2D = {'x': 1, 'y': 2, 'label': 'good'} # OK b: Point2D = {'z': 3, 'label': 'bad'} # Fails type check assert Point2D(x=1, y=2, label='first') == dict(x=1, y=2, label='first')
Para permitir el uso de esta característica con versiones más antiguas de Python que no tienen soporte para PEP 526,
TypedDict
soporta adicionalmente dos formas sintácticas equivalentes:El uso de un
dict
literal como segundo argumento:Point2D = TypedDict('Point2D', {'x': int, 'y': int, 'label': str})
El uso de argumentos nombrados:
Point2D = TypedDict('Point2D', x=int, y=int, label=str)
Deprecated since version 3.11, will be removed in version 3.13: La sintaxis de argumentos nombrados está obsoleta desde la versión 3.11 y será removida en la versión 3.13. Además, podría no estar soportada por los validadores estáticos de tipo.
También es preferible el uso de la sintaxis funcional cuando cualquiera de las llaves no sean identifiers válidos, por ejemplo porque son palabras clave o contienen guiones. Ejemplo:
# raises SyntaxError class Point2D(TypedDict): in: int # 'in' is a keyword x-y: int # name with hyphens # OK, functional syntax Point2D = TypedDict('Point2D', {'in': int, 'x-y': int})
De forma predeterminada, todas las llaves deben estar presentes en un
TypedDict
. Es posible marcar llaves individuales como no requeridas utilizandoNotRequired
: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 dePoint2D
, será posible omitir la llavelabel
.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 unFalse
literal oTrue
como valor del argumentototal
.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 utilizandoRequired
: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 tiposTypedDict
usando la sintaxis de clase. Uso:class Point3D(Point2D): z: int
Point3D
tiene tres elementos:x
,y
yz
. 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 deTypedDict
, exceptuandoGeneric
. 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(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 argumentototal
. 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__
yPoint2D.__optional_keys__
retornan objetos de la clasefrozenset
, que contienen las llaves requeridas y no requeridas, respectivamente.Las llaves marcadas con
Required
siempre aparecerán en__required_keys__
y las llaves marcadas conNotRequired
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 unTypedDict
con un valor para el argumentototal
y luego heredando de él en otroTypedDict
con un valor distinto paratotal
:>>> 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
oNotRequired
. Véase PEP 655.Distinto en la versión 3.11: Se agrega soporte para
TypedDict
genéricos.
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 comoMapping
.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 comoSequence
oIterable
.Este tipo se puede usar del siguiente modo:
T = TypeVar('T', int, float) def vec2(x: T, y: T) -> List[T]: return [x, y] def keep_positives(vector: Sequence[T]) -> List[T]: return [item for item in vector if item > 0]
Obsoleto desde la versión 3.9:
builtins.list
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 comoAbstractSet
.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 subclasesTextIO(IO[str])
yBinaryIO(IO[bytes])
representan los tipos de flujos de E/S como los retornados poropen()
.Deprecated since version 3.8, will be removed in version 3.12: El espacio de nombres
typing.io
está obsoleto y se eliminará. En su lugar, estos tipos deben importarse directamente desdetyping
.
- class typing.Pattern¶
- class typing.Match¶
Estos alias de tipo corresponden a los tipos retornados de
re.compile()
yre.match()
. Estos tipos (y las funciones correspondientes) son genéricos enAnyStr
y se pueden hacer específicos escribiendoPattern[str]
,Pattern[bytes]
,Match[str]
oMatch[bytes]
.Deprecated since version 3.8, will be removed in version 3.12: El espacio de nombres
typing.re
está obsoleto y se eliminará. En su lugar, estos tipos deben importarse directamente desdetyping
.Obsoleto desde la versión 3.9: Las clases
Pattern
yMatch
dere
ahora soportan[]
. Véase PEP 585 y Tipo Alias Genérico.
- class typing.Text¶
Text
es un alias parastr
. Ésta disponible para proporcionar un mecanismo compatible hacia delante para código en Python 2: en Python 2,Text
es un alias deunicode
.Ú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: Ya no se soporta Python 2, y la mayoría de los validadores de tipo tampoco dan soporte a la validación de tipos en código escrito en Python 2. Actualmente no está planificado remover el alias, pero se alienta a los usuarios a utilizar
str
en vez deText
allí donde sea posible.
Clase base abstracta para tipos genéricos¶
Correspondientes a las colecciones en collections.abc
¶
- class typing.AbstractSet(Sized, 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])¶
Una versión genérica de
collections.abc.ByteString
.Este tipo representa a los tipos
bytes
,bytearray
, ymemoryview
de secuencias de bytes.Como abreviación para este tipo,
bytes
se puede usar para anotar argumentos de cualquiera de los tipos mencionados arriba.Obsoleto desde la versión 3.9:
collections.abc.ByteString
ahora soporta la sintaxis de subíndice ([]
). Véase PEP 585 y Tipo Alias Genérico.
- class typing.Collection(Sized, Iterable[T_co], Container[T_co])¶
Una versión genérica de
collections.abc.Collection
Nuevo en la versión 3.6.0.
Obsoleto desde la versión 3.9:
collections.abc.Collection
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(Sized, Collection[KT], Generic[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
deGenerator
se comporta como contravariante, no covariante ni invariante.Si tu generador solo retornará valores con yield, establece
SendType
yReturnType
comoNone
: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]
oIterator[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
.
- 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
.
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 deGenerator
, 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 queGenerator
,SendType
se comporta como contravariante.Si tu generador solo retornará valores con yield, establece el
SendType
comoNone
: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]
oAsyncIterator[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.
Cuando el validador de tipos se encuentra con una llamada a
assert_type()
, emite un error si el valor no es del tipo especificado:def greet(name: str) -> None: assert_type(name, str) # OK, inferred type of `name` is `str` assert_type(name, int) # type checker error
En tiempo de ejecución, ésto retorna el primer argumento sin modificar y sin efectos secundarios.
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 unint
o unstr
, y ambas opciones son cubiertas por los casos anteriores. Si un validador de tipos encuentra que una llamada aassert_never()
es alcanzable, emitirá un error. Por ejemplo, si la anotación de tipos paraarg
fuera en cambioint | str | float
, el validador de tipos emitiría un error señalando queunreachable
es de tipofloat
. Para que una llamada aassert_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 desdetyping
. Importar el nombre desdetyping
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 tienedataclasses.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 aceptanid
yname
.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
, yslots
. Debe ser posible evaluar estáticamente el valor de estos argumentos (True
oFalse
).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ámetroeq
, el valor de éste debe tomarse porTrue
oFalse
.order_default
indica si, cuando el invocador haya omitido el parámetroorder
, el valor de éste debe tomarse porTrue
oFalse
.kw_only_default
indica si, cuando el invocador haya omitido el parámetrokw_only
, el valor de éste debe tomarse porTrue
oFalse
.field_specifiers
(especificadores de campos) especifica una lista estática de clases o funciones soportadas que describen campos, de manera similar adataclasses.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 especificandefault
nidefault_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 paradefault_factory
.kw_only
indica si el campo debe ser marcado como exclusivamente de palabra clave. Si esTrue
, el campo será exclusivamente de palabra clave. Si esFalse
no lo será. Si no se especifica, se utilizará el valor para el parámetrokw_only
especificado en el objeto decorado condataclass_transform
, o si éste tampoco está especificado, se utilizará el valor dekw_only_default
endataclass_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á directamenteNotImplementedError
. 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 deprocess
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 comoif getattr(obj, "__final__", False)
para determinar si un objetoobj
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.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 nombresglobals
ylocals
. Para una claseC
, se retorna un diccionario construido por la combinación de__annotations__
yC.__mro
en orden inverso.La función reemplaza todos los
Annotated[T, ...]
conT
de manera recursiva, a menos queinclude_extras
se defina comoTrue
( véaseAnnotated
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 aNone
. Ahora la anotación es retornada sin cambios.
- typing.get_args(tp)¶
- typing.get_origin(tp)¶
Provee introspección básica para tipos genéricos y construcciones especiales de tipado.
Para un objeto de escritura de la forma
X[Y, Z, ...]
, estas funciones retornanX
y(Y, Z, ...)
. SiX
es un alias genérico para una clase incorporada ocollections
, se normaliza a la clase original. SiX
es una unión oLiteral
contenido en otro tipo genérico, el orden de(Y, Z, ...)
puede ser diferente del orden de los argumentos originales[Y, Z, ...]
debido al tipo de almacenamiento en caché. Para objetos no admitidos, retornaNone
y()
correspondientemente. Ejemplos:assert get_origin(Dict[str, int]) is dict assert get_args(Dict[int, str]) == (int, str) assert get_origin(Union[int, str]) is Union assert get_args(Union[int, str]) == (int, str)
Nuevo en la versión 3.8.
- typing.is_typeddict(tp)¶
Compruebe si un tipo es
TypedDict
.Por ejemplo:
class Film(TypedDict): title: str year: int is_typeddict(Film) # => True is_typeddict(list | str) # => False
Nuevo en la versión 3.10.
- class typing.ForwardRef¶
Una clase utilizada para la representación de escritura interna de referencias de cadena hacia adelante. Por ejemplo,
List["SomeClass"]
se transforma implícitamente enList[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 enlist[ForwardRef("SomeClass")]
y, por lo tanto, no se resolverán automáticamente enlist[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 |
---|---|---|---|
sub-módulos |
3.8 |
3.12 |
|
Versiones |
3.9 |
No decidido |
|
|
3.11 |
No decidido |