typing — Support for type hints¶
Added in version 3.5.
Source code: Lib/typing.py
Nota
The Python runtime does not enforce function and variable type annotations. They can be used by third party tools such as type checkers, IDEs, linters, etc.
This module provides runtime support for type hints.
Consider the function below:
def surface_area_of_cube(edge_length: float) -> str:
return f"The surface area of the cube is {6 * edge_length ** 2}."
The function surface_area_of_cube takes an argument expected to
be an instance of float, as indicated by the type hint
edge_length: float. The function is expected to return an instance
of str, as indicated by the -> str hint.
While type hints can be simple classes like float or str,
they can also be more complex. The typing module provides a vocabulary of
more advanced type hints.
New features are frequently added to the typing module.
The typing_extensions package
provides backports of these new features to older versions of Python.
Ver también
- ”Guía rápida sobre los indicadores de tipo”
Una visión general de los indicadores de tipo (hospedado por mypy docs, en inglés.)
- Sección “Referencia sobre sistema de tipo” de the mypy docs
El sistema de tipos de Python es estandarizado por medio de las PEPs, así que esta referencia debe aplicarse a la mayoría de validadores de tipo de Python. (Algunas partes pueden referirse específicamente a mypy.)
- «Static Typing with Python»
Documentación independiente del validador de tipos escrita por la comunidad que detalla las características del sistema de tipos, herramientas útiles relacionadas con el tipado y mejores prácticas.
Specification for the Python Type System¶
The canonical, up-to-date specification of the Python type system can be found at «Specification for the Python type system».
Alias de tipo¶
Un alias de tipo se define usando la declaración type, el cual crea una instancia de TypeAliasType. En este ejemplo, Vector y list[float] serán tratados de manera equivalente a los validadores de tipo estático:
type Vector = list[float]
def scale(scalar: float, vector: Vector) -> Vector:
return [scalar * num for num in vector]
# passes type checking; a list of floats qualifies as a Vector.
new_vector = scale(2.0, [1.0, -4.2, 5.4])
Los alias de tipo son útiles para simplificar firmas de tipo complejas. Por ejemplo:
from collections.abc import Sequence
type ConnectionOptions = dict[str, str]
type Address = tuple[str, int]
type Server = tuple[Address, ConnectionOptions]
def broadcast_message(message: str, servers: Sequence[Server]) -> None:
...
# The static type checker will treat the previous type signature as
# being exactly equivalent to this one.
def broadcast_message(
message: str,
servers: Sequence[tuple[tuple[str, int], dict[str, str]]]
) -> None:
...
La declaración type es nueva en Python 3.12. Para compatibilidad con versiones anteriores, los alias de tipo también se pueden crear mediante una asignación simple.:
Vector = list[float]
O marcarse con TypeAlias para dejar explícito que se trata de un alias de tipo, no de una asignación de variable normal:
from typing import TypeAlias
Vector: TypeAlias = list[float]
NewType¶
Use la clase auxiliar NewType para crear tipos distintos:
from typing import NewType
UserId = NewType('UserId', int)
some_id = UserId(524313)
El validador estático de tipos tratará el nuevo tipo como si fuera una subclase del tipo original. Esto es útil para capturar errores lógicos:
def get_user_name(user_id: UserId) -> str:
...
# passes type checking
user_a = get_user_name(UserId(42351))
# fails type checking; an int is not a UserId
user_b = get_user_name(-1)
Se pueden realizar todas las operaciones de int en una variable de tipo UserId, pero el resultado siempre será de tipo int. Esto permite pasar un UserId allí donde se espere un int, pero evitará la creación accidental de un UserId de manera incorrecta:
# 'output' is of type 'int', not 'UserId'
output = UserId(23413) + UserId(54341)
Tenga en cuenta que estas validaciones solo las aplica el validador de tipo estático. En tiempo de ejecución, la declaración Derived = NewType('Derived', Base) hará que Derived sea una clase que retorna inmediatamente cualquier parámetro que le pase. Eso significa que la expresión Derived(some_value) no crea una nueva clase ni introduce mucha sobrecarga más allá de la de una llamada de función regular.
Más concretamente, la expresión some_value is Derived(some_value) será siempre verdadera en tiempo de ejecución.
No es válido crear un subtipo de Derived:
from typing import NewType
UserId = NewType('UserId', int)
# Fails at runtime and does not pass type checking
class AdminUserId(UserId): pass
Sin embargo, es posible crear un NewType basado en un NewType “derivado”:
from typing import NewType
UserId = NewType('UserId', int)
ProUserId = NewType('ProUserId', UserId)
y la comprobación de tipo para ProUserId funcionará como se espera.
Véase PEP 484 para más detalle.
Nota
Recuerde que el uso de alias de tipo implica que los dos tipos son equivalentes entre sí. Haciendo type Alias = Original provocará que el validador estático de tipos trate Alias como algo exactamente equivalente a Original en todos los casos. Esto es útil para cuando se quiera simplificar indicadores de tipo complejos.
En cambio, NewType declara un tipo que es subtipo de otro. Haciendo Derived = NewType('Derived', Original) hará que el Validador estático de tipos trate Derived como una subclase de Original, lo que implica que un valor de tipo Original no puede ser usado allí donde se espere un valor de tipo Derived. Esto es útil para prevenir errores lógicos con un coste de ejecución mínimo.
Added in version 3.5.2.
Distinto en la versión 3.10: NewType es ahora una clase en lugar de una función. Existe un costo de tiempo de ejecución adicional cuando se llama a NewType a través de una función normal.
Distinto en la versión 3.11: El rendimiento al llamar NewType ha sido restaurado a su nivel en Python 3.9.
Anotaciones en objetos invocables¶
Functions – or other callable objects – can be annotated using
collections.abc.Callable or deprecated typing.Callable.
Callable[[int], str] signifies a function that takes a single parameter
of type int and returns a str.
Por ejemplo:
from collections.abc import Callable, Awaitable
def feeder(get_next_item: Callable[[], str]) -> None:
... # Body
def async_query(on_success: Callable[[int], None],
on_error: Callable[[int, Exception], None]) -> None:
... # Body
async def on_update(value: str) -> None:
... # Body
callback: Callable[[str], Awaitable[None]] = on_update
La sintaxis de suscripción siempre debe utilizarse con exactamente dos valores: una lista de argumentos y el tipo de retorno. La lista de argumentos debe ser una lista de tipos, un ParamSpec, Concatenate o una elipsis. El tipo de retorno debe ser un único tipo.
Si se proporciona una elipsis como lista de argumentos, indica que sería aceptable un invocable con cualquier lista de parámetros arbitraria:
def concat(x: str, y: str) -> str:
return x + y
x: Callable[..., str]
x = str # OK
x = concat # Also OK
Callable cannot express complex signatures such as functions that take a
variadic number of arguments, overloaded functions, or
functions that have keyword-only parameters. However, these signatures can be
expressed by defining a Protocol class with a
__call__() method:
from collections.abc import Iterable
from typing import Protocol
class Combiner(Protocol):
def __call__(self, *vals: bytes, maxlen: int | None = None) -> list[bytes]: ...
def batch_proc(data: Iterable[bytes], cb_results: Combiner) -> bytes:
for item in data:
...
def good_cb(*vals: bytes, maxlen: int | None = None) -> list[bytes]:
...
def bad_cb(*vals: bytes, maxitems: int | None) -> list[bytes]:
...
batch_proc([], good_cb) # OK
batch_proc([], bad_cb) # Error! Argument 2 has incompatible type because of
# different name and kind in the callback
Los invocables que toman otros invocables como argumentos pueden indicar que sus tipos de parámetros dependen unos de otros utilizando ParamSpec. Además, si ese invocable agrega o elimina argumentos de otros invocables, se puede utilizar el operador Concatenate. Toman la forma Callable[ParamSpecVariable, ReturnType] y Callable[Concatenate[Arg1Type, Arg2Type, ..., ParamSpecVariable], ReturnType] respectivamente.
Distinto en la versión 3.10: Callable ahora es compatible con ParamSpec y Concatenate. Consulte PEP 612 para obtener más información.
Ver también
La documentación de ParamSpec y Concatenate proporciona ejemplos de uso en Callable.
Genéricos¶
Dado que la información de tipo sobre los objetos guardados en contenedores no se puede inferir estáticamente de manera genérica, muchas clases de contenedor en la biblioteca estándar admiten suscripción para indicar los tipos esperados de elementos de contenedor.
from collections.abc import Mapping, Sequence
class Employee: ...
# Sequence[Employee] indicates that all elements in the sequence
# must be instances of "Employee".
# Mapping[str, str] indicates that all keys and all values in the mapping
# must be strings.
def notify_by_email(employees: Sequence[Employee],
overrides: Mapping[str, str]) -> None: ...
Funciones y clases genéricas pueden ser parametrizadas usando type parameter syntax:
from collections.abc import Sequence
def first[T](l: Sequence[T]) -> T: # Function is generic over the TypeVar "T"
return l[0]
O utilizando directamente la fábrica TypeVar:
from collections.abc import Sequence
from typing import TypeVar
U = TypeVar('U') # Declare type variable "U"
def second(l: Sequence[U]) -> U: # Function is generic over the TypeVar "U"
return l[1]
Distinto en la versión 3.12: El soporte sintáctico para genéricos es nuevo en Python 3.12.
Anotaciones en tuplas¶
En la mayoría de los contenedores de Python, el sistema de tipado supone que todos los elementos del contenedor serán del mismo tipo. Por ejemplo:
from collections.abc import Mapping
# Type checker will infer that all elements in ``x`` are meant to be ints
x: list[int] = []
# Type checker error: ``list`` only accepts a single type argument:
y: list[int, str] = [1, 'foo']
# Type checker will infer that all keys in ``z`` are meant to be strings,
# and that all values in ``z`` are meant to be either strings or ints
z: Mapping[str, str | int] = {}
list solo acepta un argumento de tipo, por lo que un validador de tipos emitiría un error en la asignación y anterior. De manera similar, Mapping solo acepta dos argumentos de tipo: el primero indica el tipo de las claves y el segundo indica el tipo de los valores.
Sin embargo, a diferencia de la mayoría de los demás contenedores de Python, es común en el código idiomático de Python que las tuplas tengan elementos que no sean todos del mismo tipo. Por este motivo, las tuplas son un caso especial en el sistema de tipado de Python. tuple acepta cualquier número de argumentos de tipo:
# OK: ``x`` is assigned to a tuple of length 1 where the sole element is an int
x: tuple[int] = (5,)
# OK: ``y`` is assigned to a tuple of length 2;
# element 1 is an int, element 2 is a str
y: tuple[int, str] = (5, "foo")
# Error: the type annotation indicates a tuple of length 1,
# but ``z`` has been assigned to a tuple of length 3
z: tuple[int] = (1, 2, 3)
Para indicar una tupla que podría tener cualquier tamaño y en la que todos los elementos son del mismo tipo T, utilice tuple[T, ...]. Para indicar una tupla vacía, utilice tuple[()]. El uso de tuple simple como anotación es equivalente a utilizar tuple[Any, ...]:
x: tuple[int, ...] = (1, 2)
# These reassignments are OK: ``tuple[int, ...]`` indicates x can be of any length
x = (1, 2, 3)
x = ()
# This reassignment is an error: all elements in ``x`` must be ints
x = ("foo", "bar")
# ``y`` can only ever be assigned to an empty tuple
y: tuple[()] = ()
z: tuple = ("foo", "bar")
# These reassignments are OK: plain ``tuple`` is equivalent to ``tuple[Any, ...]``
z = (1, 2, 3)
z = ()
El tipo de objetos de clase¶
A variable annotated with C may accept a value of type C. In
contrast, a variable annotated with type[C] (or deprecated
typing.Type[C]) may accept values that are classes
themselves – specifically, it will accept the class object of C. For
example:
a = 3 # Has type ``int``
b = int # Has type ``type[int]``
c = type(a) # Also has type ``type[int]``
Tenga en cuenta que type[C] es covariante:
class User: ...
class ProUser(User): ...
class TeamUser(User): ...
def make_new_user(user_class: type[User]) -> User:
# ...
return user_class()
make_new_user(User) # OK
make_new_user(ProUser) # Also OK: ``type[ProUser]`` is a subtype of ``type[User]``
make_new_user(TeamUser) # Still fine
make_new_user(User()) # Error: expected ``type[User]`` but got ``User``
make_new_user(int) # Error: ``type[int]`` is not a subtype of ``type[User]``
Los únicos parámetros legales para type son las clases, Any, variables de tipo y uniones de cualquiera de estos tipos. Por ejemplo:
def new_non_team_user(user_class: type[BasicUser | ProUser]): ...
new_non_team_user(BasicUser) # OK
new_non_team_user(ProUser) # OK
new_non_team_user(TeamUser) # Error: ``type[TeamUser]`` is not a subtype
# of ``type[BasicUser | ProUser]``
new_non_team_user(User) # Also an error
type[Any] es equivalente a type, que es la raíz de la jerarquía de metaclases de Python.
Annotating generators and coroutines¶
A generator can be annotated using the generic type
Generator[YieldType, SendType, ReturnType].
For example:
def echo_round() -> Generator[int, float, str]:
sent = yield 0
while sent >= 0:
sent = yield round(sent)
return 'Done'
Note that unlike many other generic classes in the standard library,
the SendType of Generator behaves
contravariantly, not covariantly or invariantly.
The SendType and ReturnType parameters default to None:
def infinite_stream(start: int) -> Generator[int]:
while True:
yield start
start += 1
It is also possible to set these types explicitly:
def infinite_stream(start: int) -> Generator[int, None, None]:
while True:
yield start
start += 1
Simple generators that only ever yield values can also be annotated
as having a return type of either
Iterable[YieldType]
or Iterator[YieldType]:
def infinite_stream(start: int) -> Iterator[int]:
while True:
yield start
start += 1
Async generators are handled in a similar fashion, but don’t
expect a ReturnType type argument
(AsyncGenerator[YieldType, SendType]).
The SendType argument defaults to None, so the following definitions
are equivalent:
async def infinite_stream(start: int) -> AsyncGenerator[int]:
while True:
yield start
start = await increment(start)
async def infinite_stream(start: int) -> AsyncGenerator[int, None]:
while True:
yield start
start = await increment(start)
As in the synchronous case,
AsyncIterable[YieldType]
and AsyncIterator[YieldType] are
available as well:
async def infinite_stream(start: int) -> AsyncIterator[int]:
while True:
yield start
start = await increment(start)
Coroutines can be annotated using
Coroutine[YieldType, SendType, ReturnType].
Generic arguments correspond to those of Generator,
for example:
from collections.abc import Coroutine
c: Coroutine[list[str], str, int] # Some coroutine defined elsewhere
x = c.send('hi') # Inferred type of 'x' is list[str]
async def bar() -> None:
y = await c # Inferred type of 'y' is int
Tipos genéricos definidos por el usuario¶
Una clase definida por el usuario puede ser definida como una clase genérica.
from logging import Logger
class LoggedVar[T]:
def __init__(self, value: T, name: str, logger: Logger) -> None:
self.name = name
self.logger = logger
self.value = value
def set(self, new: T) -> None:
self.log('Set ' + repr(self.value))
self.value = new
def get(self) -> T:
self.log('Get ' + repr(self.value))
return self.value
def log(self, message: str) -> None:
self.logger.info('%s: %s', self.name, message)
This syntax indicates that the class LoggedVar is parameterised around a
single type variable T . This also makes T valid as
a type within the class body.
Las clases genéricas heredan implícitamente de Generic. Para compatibilidad con Python 3.11 y versiones anteriores, también es posible heredar explícitamente de Generic para indicar una clase genérica:
from typing import TypeVar, Generic
T = TypeVar('T')
class LoggedVar(Generic[T]):
...
Las clases genéricas tienen métodos __class_getitem__(), lo que significa que se pueden parametrizar en tiempo de ejecución (por ejemplo, LoggedVar[int] a continuación):
from collections.abc import Iterable
def zero_all_vars(vars: Iterable[LoggedVar[int]]) -> None:
for var in vars:
var.set(0)
Un tipo genérico puede tener un numero cualquiera de variables de tipo. Se permiten todas las variaciones de TypeVar para ser usadas como parámetros de un tipo genérico:
from typing import TypeVar, Generic, Sequence
class WeirdTrio[T, B: Sequence[bytes], S: (int, str)]:
...
OldT = TypeVar('OldT', contravariant=True)
OldB = TypeVar('OldB', bound=Sequence[bytes], covariant=True)
OldS = TypeVar('OldS', int, str)
class OldWeirdTrio(Generic[OldT, OldB, OldS]):
...
Cada argumento de variable de tipo de Generic debe ser distinto. Por lo tanto, esto no es válido:
from typing import TypeVar, Generic
...
class Pair[M, M]: # SyntaxError
...
T = TypeVar('T')
class Pair(Generic[T, T]): # INVALID
...
Las clases genéricas también pueden heredar de otras clases:
from collections.abc import Sized
class LinkedList[T](Sized):
...
Al heredar de clases genéricas, algunos parámetros de tipo podrían ser fijos:
from collections.abc import Mapping
class MyDict[T](Mapping[str, T]):
...
En este caso MyDict tiene un solo parámetro, T.
El uso de una clase genérica sin especificar parámetros de tipo supone Any para cada posición. En el siguiente ejemplo, MyIterable no es genérico, sino que hereda implícitamente de Iterable[Any]:
from collections.abc import Iterable
class MyIterable(Iterable): # Same as Iterable[Any]
...
También se admiten alias de tipos genéricos definidos por el usuario. Ejemplos:
from collections.abc import Iterable
type Response[S] = Iterable[S] | int
# Return type here is same as Iterable[str] | int
def response(query: str) -> Response[str]:
...
type Vec[T] = Iterable[tuple[T, T]]
def inproduct[T: (int, float, complex)](v: Vec[T]) -> T: # Same as Iterable[tuple[T, T]]
return sum(x*y for x, y in v)
Para compatibilidad con versiones anteriores, también se pueden crear alias de tipos genéricos mediante una asignación simple:
from collections.abc import Iterable
from typing import TypeVar
S = TypeVar("S")
Response = Iterable[S] | int
Distinto en la versión 3.7: Generic ya no posee una metaclase personalizable.
Distinto en la versión 3.12: La compatibilidad sintáctica con genéricos y alias de tipo es una novedad en la versión 3.12. Antes, las clases genéricas debían heredar explícitamente de Generic o contener una variable de tipo en una de sus bases.
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]]
También se pueden crear clases genéricas sobre ParamSpec utilizando herencia explícita de Generic. En este caso, no se utiliza **:
from typing import ParamSpec, Generic
P = ParamSpec('P')
class Z(Generic[P]):
...
Otra diferencia entre TypeVar y ParamSpec es que una variable genérica con una sola especificación de parámetros aceptará listas de parámetros en los formatos X[[Type1, Type2, ...]] y también X[Type1, Type2, ...] por razones estéticas. Internamente, el último se convierte al primero, por lo que los siguientes son equivalentes:
>>> class X[**P]: ...
...
>>> X[int, str]
__main__.X[[int, str]]
>>> X[[int, str]]
__main__.X[[int, str]]
Tenga en cuenta que los genéricos con ParamSpec pueden no tener __parameters__ correctos después de la sustitución en algunos casos porque están destinados principalmente a la verificación de tipos estáticos.
Distinto en la versión 3.10: Generic ahora se puede parametrizar sobre expresiones de parámetros. Consulte ParamSpec y PEP 612 para obtener más detalles.
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 esta funcionalidad, lo que resulta poco pythónico (idiomático) y poco ajustado a lo que uno normalmente haría en un código Python tipado dinámicamente. Por ejemplo, esto sí se ajusta al PEP 484:
from collections.abc import Sized, Iterable, Iterator
class Bucket(Sized, Iterable[int]):
...
def __len__(self) -> int: ...
def __iter__(self) -> Iterator[int]: ...
El PEP 544 permite resolver este problema al permitir escribir el código anterior sin una clase base explícita en la definición de la clase, permitiendo que el Validador estático de tipo considere implícitamente que Bucket es un subtipo tanto de Sized como de Iterable[int]. Esto se conoce como tipado estructural (o duck-typing estático):
from collections.abc import Iterator, Iterable
class Bucket: # Note: no base classes
...
def __len__(self) -> int: ...
def __iter__(self) -> Iterator[int]: ...
def collect(items: Iterable[int]) -> int: ...
result = collect(Bucket()) # Passes type check
Asimismo, creando subclases de la clase especial Protocol, el usuario puede definir nuevos protocolos personalizados y beneficiarse del tipado estructural (véanse los ejemplos de abajo).
Contenido del módulo¶
El módulo typing define las siguientes clases, funciones y decoradores.
Primitivos especiales de tipado¶
Tipos especiales¶
Estos pueden ser usados como tipos en anotaciones. No soportan suscripción usando [].
- typing.Any¶
Tipo especial que indica un tipo sin restricciones.
Distinto en la versión 3.11: Ahora es posible utilizar
Anycomo una clase base. Esto puede ser útil para evitar errores del validador de tipos con clases que pueden hacer uso del duck typing en cualquier punto, o que sean altamente dinámicas.
- typing.AnyStr¶
Una variables de tipo restringida.
Definición:
AnyStr = TypeVar('AnyStr', str, bytes)
AnyStrestá pensado para ser utilizado por funciones que pueden aceptar argumentosstrobytespero que no puedan permitir que los dos se mezclen.Por ejemplo:
def concat(a: AnyStr, b: AnyStr) -> AnyStr: return a + b concat("foo", "bar") # OK, output has type 'str' concat(b"foo", b"bar") # OK, output has type 'bytes' concat("foo", b"bar") # Error, cannot mix str and bytes
Tenga en cuenta que, a pesar de su nombre,
AnyStrno tiene nada que ver con el tipoAny, ni significa “cualquier cadena de caracteres”. En particular,AnyStrystr | bytesson diferentes entre sí y tienen diferentes casos de uso:# Invalid use of AnyStr: # The type variable is used only once in the function signature, # so cannot be "solved" by the type checker def greet_bad(cond: bool) -> AnyStr: return "hi there!" if cond else b"greetings!" # The better way of annotating this function: def greet_proper(cond: bool) -> str | bytes: return "hi there!" if cond else b"greetings!"
Deprecated since version 3.13, will be removed in version 3.18: Deprecated in favor of the new type parameter syntax. Use
class A[T: (str, bytes)]: ...instead of importingAnyStr. See PEP 695 for more details.In Python 3.16,
AnyStrwill be removed fromtyping.__all__, and deprecation warnings will be emitted at runtime when it is accessed or imported fromtyping.AnyStrwill be removed fromtypingin Python 3.18.
- typing.LiteralString¶
Tipo especial que incluye sólo cadenas de caracteres literales.
Cualquier cadena de caracteres literal es compatible con
LiteralString, al igual que cualquier otroLiteralString. Sin embargo, un objeto cuyo tipo sea simplementestrno lo es. Una cadena de caracteres creada mediante la composición de objetos cuyo tipo seaLiteralStringtambién es aceptable comoLiteralString.Por ejemplo:
def run_query(sql: LiteralString) -> None: ... def caller(arbitrary_string: str, literal_string: LiteralString) -> None: run_query("SELECT * FROM students") # OK run_query(literal_string) # OK run_query("SELECT * FROM " + literal_string) # OK run_query(arbitrary_string) # type checker error run_query( # type checker error f"SELECT * FROM students WHERE name = {arbitrary_string}" )
LiteralStringes útil para API sensibles en las que cadenas de caracteres arbitrarias generadas por el usuario podrían generar problemas. Por ejemplo, los dos casos anteriores que generan errores de verificación de tipos podrían ser vulnerables a un ataque de inyección SQL.Véase PEP 675 para más detalle.
Added in version 3.11.
- typing.Never¶
- typing.NoReturn¶
NeverandNoReturnrepresent the bottom type, a type that has no members.They can be used to indicate that a function never returns, such as
sys.exit():from typing import Never # or NoReturn def stop() -> Never: raise RuntimeError('no way')
Or to define a function that should never be called, as there are no valid arguments, such as
assert_never():from typing import Never # or NoReturn def never_call_me(arg: Never) -> None: pass def int_or_str(arg: int | str) -> None: never_call_me(arg) # type checker error match arg: case int(): print("It's an int") case str(): print("It's a str") case _: never_call_me(arg) # OK, arg is of type Never (or NoReturn)
NeverandNoReturnhave the same meaning in the type system and static type checkers treat both equivalently.Added in version 3.6.2: Added
NoReturn.Added in version 3.11: Added
Never.
- typing.Self¶
Tipo especial que representa la clase capturada actual.
Por ejemplo:
from typing import Self, reveal_type class Foo: def return_self(self) -> Self: ... return self class SubclassOfFoo(Foo): pass reveal_type(Foo().return_self()) # Revealed type is "Foo" reveal_type(SubclassOfFoo().return_self()) # Revealed type is "SubclassOfFoo"
Esta anotación es semánticamente equivalente a lo siguiente, aunque de una manera más sucinta:
from typing import TypeVar Self = TypeVar("Self", bound="Foo") class Foo: def return_self(self: Self) -> Self: ... return self
En general, si algo devuelve
self, como en los ejemplos anteriores, se debe utilizarSelfen la anotación del retorno. SiFoo.return_selfse anotó como que devuelve”Foo”, entonces el validador de tipos inferiría que el objeto devuelto desdeSubclassOfFoo.return_selfes del tipoFooen lugar deSubclassOfFoo.Otros casos de uso comunes incluyen:
classmethodusados como constructores alternativos y retornan instancias del parámetrocls.Anotar un método
__enter__()que retorna self.
No debe utilizar
Selfcomo anotación de retorno si no se garantiza que el método devuelva una instancia de una subclase cuando la clase sea heredada:class Eggs: # Self would be an incorrect return annotation here, # as the object returned is always an instance of Eggs, # even in subclasses def returns_eggs(self) -> "Eggs": return Eggs()
Véase PEP 673 para más detalle.
Added in version 3.11.
- typing.TypeAlias¶
Anotación especial para declarar explícitamente un alias de tipo.
Por ejemplo:
from typing import TypeAlias Factors: TypeAlias = list[int]
TypeAliases particularmente útil en versiones anteriores de Python para anotar alias que utilizan referencias para versiones posteriores, ya que puede ser difícil para los validadores de tipos distinguirlos de las asignaciones de variables normales:from typing import Generic, TypeAlias, TypeVar T = TypeVar("T") # "Box" does not exist yet, # so we have to use quotes for the forward reference on Python <3.12. # Using ``TypeAlias`` tells the type checker that this is a type alias declaration, # not a variable assignment to a string. BoxOfStrings: TypeAlias = "Box[str]" class Box(Generic[T]): @classmethod def make_box_of_strings(cls) -> BoxOfStrings: ...
Ver PEP 613 para más detalle.
Added in version 3.10.
Obsoleto desde la versión 3.12:
TypeAliasha sido descontinuado en favor de la declaracióntype, la cual crea instancias deTypeAliasTypey que admite de forma nativa referencias de versiones posteriores de Python. Tenga en cuenta que, si bienTypeAliasyTypeAliasTypetienen propósitos similares y tienen nombres similares, son distintos y el último no es el tipo del primero. La eliminación deTypeAliasno está prevista actualmente, pero se recomienda a los usuarios que migren a las declaracionestype.
Formas especiales¶
Estos se pueden utilizar como tipos en anotaciones. Todos admiten la suscripción mediante [], pero cada uno tiene una sintaxis única.
- typing.Union¶
Tipo de unión;
Union[X, Y]es equivalente aX | Yy 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]
However, this does not apply to unions referenced through a type alias, to avoid forcing evaluation of the underlying
TypeAliasType:type A = Union[int, str] Union[A, float] != Union[int, str, float]
Las uniones con un solo argumento se eliminan, p. ej.:
Union[int] == int # The constructor actually returns int
Argumentos repetidos se omiten, p. ej.:
Union[int, str, int] == Union[int, str] == int | str
Cuando se comparan uniones, el orden de los argumentos se ignoran, p. ej.:
Union[int, str] == Union[str, int]
No es posible crear una subclase o instanciar un
Union.No es posible escribir
Union[X][Y].
Distinto en la versión 3.7: No elimina subclases explícitas de una unión en tiempo de ejecución.
Distinto en la versión 3.10: Las uniones ahora se pueden escribir como
X | Y. Consulte union type expressions.
- typing.Optional¶
Optional[X]es equivalente 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
Optionalen 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.Concatenate¶
Forma especial para anotar funciones de orden superior.
Concatenatese puede utilizar junto con Callable yParamSpecpara anotar un objeto invocable de orden superior que agrega, elimina o transforma parámetros de otro objeto invocable. El uso se realiza en el formatoConcatenate[Arg1Type, Arg2Type, ..., ParamSpecVariable].Concatenateactualmente solo es válido cuando se utiliza como primer argumento de un Callable. El último parámetro deConcatenatedebe ser unParamSpeco elipsis.Por ejemplo, para anotar un decorador
with_lockque proporciona unthreading.Locka la función decorada,Concatenatepuede usarse para indicar quewith_lockespera un invocable que toma unLockcomo primer argumento y retorna un invocable con un tipo de firma diferente. En este caso, elParamSpecindica 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 # Use this lock to ensure that only one thread is executing a function # at any time. my_lock = Lock() def with_lock[**P, R](f: Callable[Concatenate[Lock, P], R]) -> Callable[P, R]: '''A type-safe decorator which provides a lock.''' def inner(*args: P.args, **kwargs: P.kwargs) -> R: # Provide the lock as the first argument. return f(my_lock, *args, **kwargs) return inner @with_lock def sum_threadsafe(lock: Lock, numbers: list[float]) -> float: '''Add a list of numbers together in a thread-safe manner.''' with lock: return sum(numbers) # We don't need to pass in the lock ourselves thanks to the decorator. sum_threadsafe([1.1, 2.2, 3.3])
Added in version 3.10.
Ver también
PEP 612 - Variables de especificación de parámetros (el PEP que introdujo
ParamSpecyConcatenate)
- typing.Literal¶
Tipo especial que solo incluye cadenas literales.
Literalse puede utilizar para indicar a los validadores de tipos que el objeto anotado tiene un valor equivalente a uno de los literales proporcionados.Por ejemplo:
def validate_simple(data: Any) -> Literal[True]: # always returns True ... type Mode = Literal['r', 'rb', 'w', 'wb'] def open_helper(file: str, mode: Mode) -> str: ... open_helper('/some/path', 'r') # Passes type check open_helper('/other/path', 'typo') # Error in type checker
Literal[...]no puede ser derivado. En tiempo de ejecución, se permite un valor arbitrario como argumento de tipo deLiteral[...], pero los validadores de tipos pueden imponer sus restricciones. Véase PEP 585 para más detalles sobre tipos literales.Additional details:
The arguments must be literal values and there must be at least one.
Nested
Literaltypes are flattened, e.g.:assert Literal[Literal[1, 2], 3] == Literal[1, 2, 3]
However, this does not apply to
Literaltypes referenced through a type alias, to avoid forcing evaluation of the underlyingTypeAliasType:type A = Literal[1, 2] assert Literal[A, 3] != Literal[1, 2, 3]
Argumentos repetidos se omiten, p. ej.:
assert Literal[1, 2, 1] == Literal[1, 2]
When comparing literals, the argument order is ignored, e.g.:
assert Literal[1, 2] == Literal[2, 1]
You cannot subclass or instantiate a
Literal.You cannot write
Literal[X][Y].
Added in version 3.8.
- 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
ClassVarsolo acepta tipos y no admite más niveles de subíndices.ClassVarno es un clase en sí misma, y no debe ser usado conisinstance()oissubclass().ClassVarno modifica el comportamiento de Python en tiempo de ejecución pero puede ser utilizado por validadores de terceros. Por ejemplo, un validador de tipos puede marcar el siguiente código como erróneo:enterprise_d = Starship(3000) enterprise_d.stats = {} # Error, setting class variable on instance Starship.stats = {} # This is OK
Added in version 3.5.3.
- typing.Final¶
Construcción de tipado especial para indicar nombres finales a los validadores de tipos.
Los nombres finales no se pueden reasignar en ningún ámbito. Los nombres finales declarados en ámbitos de clase no se pueden anular en subclases.
Por ejemplo:
MAX_SIZE: Final = 9000 MAX_SIZE += 1 # Error reported by type checker class Connection: TIMEOUT: Final[int] = 10 class FastConnector(Connection): TIMEOUT = 1 # Error reported by type checker
No hay comprobación en tiempo de ejecución para estas propiedades. Véase PEP 591 para más detalles.
Added in version 3.8.
- typing.Required¶
Construcción de tipado especial para marcar una clave
TypedDictcomo requerida.Esto es útil principalmente para TypedDicts
total=False. VeaTypedDicty PEP 655 para obtener más detalles.Added in version 3.11.
- typing.NotRequired¶
Construcción de tipado especial para marcar una clave
TypedDictcomo potencialmente faltante.Véase
TypedDicty PEP 655 para más detalle.Added in version 3.11.
- typing.ReadOnly¶
A special typing construct to mark an item of a
TypedDictas read-only.Por ejemplo:
class Movie(TypedDict): title: ReadOnly[str] year: int def mutate_movie(m: Movie) -> None: m["year"] = 1999 # allowed m["title"] = "The Matrix" # typechecker error
There is no runtime checking for this property.
See
TypedDictand PEP 705 for more details.Added in version 3.13.
- typing.Annotated¶
Forma de escritura especial para agregar metadatos específicos del contexto a una anotación.
Agregue metadatos
xa un tipoTdeterminado mediante la anotaciónAnnotated[T, x]. Los metadatos agregados medianteAnnotatedpueden usarse con herramientas de análisis estático o en tiempo de ejecución. En tiempo de ejecución, los metadatos se almacenan en un atributo__metadata__.Si una biblioteca o herramienta encuentra una anotación
Annotated[T, x]y no tiene una lógica especial para los metadatos, debe ignorar los metadatos y simplemente tratar la anotación comoT. Como tal,Annotatedpuede ser útil para el código que desea usar anotaciones para fines fuera del sistema de tipado estático de Python.El uso de
Annotated[T, x]como anotación aún permite la verificación de tipos estática deT, ya que los validadores de tipos simplemente ignorarán los metadatosx. De esta manera,Annotateddifiere del decorador@no_type_check, que también se puede usar para agregar anotaciones fuera del alcance del sistema de tipado, pero deshabilita por completo la verificación de tipos para una función o clase.The responsibility of how to interpret the metadata lies with the tool or library encountering an
Annotatedannotation. A tool or library encountering anAnnotatedtype can scan through the metadata elements to determine if they are of interest (e.g., usingisinstance()).- Annotated[<type>, <metadata>]
A continuación se muestra un ejemplo de cómo podría utilizar
Annotatedpara agregar metadatos a las anotaciones de tipo si estuviera realizando un análisis de rango:@dataclass class ValueRange: lo: int hi: int T1 = Annotated[int, ValueRange(-10, 5)] T2 = Annotated[T1, ValueRange(-20, 3)]
The first argument to
Annotatedmust be a valid type. Multiple metadata elements can be supplied asAnnotatedsupports variadic arguments. The order of the metadata elements is preserved and matters for equality checks:@dataclass class ctype: kind: str a1 = Annotated[int, ValueRange(3, 10), ctype("char")] a2 = Annotated[int, ctype("char"), ValueRange(3, 10)] assert a1 != a2 # Order matters
Depende de la herramienta que consume las anotaciones decidir si el cliente puede agregar varios elementos de metadatos a una anotación y cómo fusionar esas anotaciones.
Los tipos anidados
Annotatedse aplanan. El orden de los elementos de metadatos comienza con la anotación más interna:assert Annotated[Annotated[int, ValueRange(3, 10)], ctype("char")] == Annotated[ int, ValueRange(3, 10), ctype("char") ]
However, this does not apply to
Annotatedtypes referenced through a type alias, to avoid forcing evaluation of the underlyingTypeAliasType:type From3To10[T] = Annotated[T, ValueRange(3, 10)] assert Annotated[From3To10[int], ctype("char")] != Annotated[ int, ValueRange(3, 10), ctype("char") ]
Los elementos de metadatos duplicados no se eliminan:
assert Annotated[int, ValueRange(3, 10)] != Annotated[ int, ValueRange(3, 10), ValueRange(3, 10) ]
Annotatedse puede utilizar con alias anidados y genéricos:@dataclass class MaxLen: value: int type Vec[T] = Annotated[list[tuple[T, T]], MaxLen(10)] # When used in a type annotation, a type checker will treat "V" the same as # ``Annotated[list[tuple[int, int]], MaxLen(10)]``: type V = Vec[int]
No se puede utilizar
Annotatedcon unTypeVarTupledescomprimido:type Variadic[*Ts] = Annotated[*Ts, Ann1] = Annotated[T1, T2, T3, ..., Ann1] # NOT valid
where
T1,T2, … areTypeVars. This is invalid as only one type should be passed to Annotated.De forma predeterminada,
get_type_hints()elimina los metadatos de las anotaciones. Paseinclude_extras=Truepara conservar los metadatos:>>> from typing import Annotated, get_type_hints >>> def func(x: Annotated[int, "metadata"]) -> None: pass ... >>> get_type_hints(func) {'x': <class 'int'>, 'return': <class 'NoneType'>} >>> get_type_hints(func, include_extras=True) {'x': typing.Annotated[int, 'metadata'], 'return': <class 'NoneType'>}
En tiempo de ejecución, los metadatos asociados con un tipo
Annotatedse pueden recuperar a través del atributo__metadata__:>>> from typing import Annotated >>> X = Annotated[int, "very", "important", "metadata"] >>> X typing.Annotated[int, 'very', 'important', 'metadata'] >>> X.__metadata__ ('very', 'important', 'metadata')
If you want to retrieve the original type wrapped by
Annotated, use the__origin__attribute:>>> from typing import Annotated, get_origin >>> Password = Annotated[str, "secret"] >>> Password.__origin__ <class 'str'>
Note that using
get_origin()will returnAnnotateditself:>>> get_origin(Password) typing.Annotated
Ver también
- PEP 593 - Anotaciones flexibles de funciones y variables
El PEP introduce
Annotateden la biblioteca estándar.
Added in version 3.9.
- typing.TypeIs¶
Special typing construct for marking user-defined type predicate functions.
TypeIscan be used to annotate the return type of a user-defined type predicate function.TypeIsonly accepts a single type argument. At runtime, functions marked this way should return a boolean and take at least one positional argument.TypeIsaims to benefit type narrowing – a technique used by static type checkers to determine a more precise type of an expression within a program’s code flow. Usually type narrowing is done by analyzing conditional code flow and applying the narrowing to a block of code. The conditional expression here is sometimes referred to as a «type predicate»:def is_str(val: str | float): # "isinstance" type predicate if isinstance(val, str): # Type of ``val`` is narrowed to ``str`` ... else: # Else, type of ``val`` is narrowed to ``float``. ...
Sometimes it would be convenient to use a user-defined boolean function as a type predicate. Such a function should use
TypeIs[...]orTypeGuardas its return type to alert static type checkers to this intention.TypeIsusually has more intuitive behavior thanTypeGuard, but it cannot be used when the input and output types are incompatible (e.g.,list[object]tolist[int]) or when the function does not returnTruefor all instances of the narrowed type.Using
-> TypeIs[NarrowedType]tells the static type checker that for a given function:El valor de retorno es un booleano.
If the return value is
True, the type of its argument is the intersection of the argument’s original type andNarrowedType.If the return value is
False, the type of its argument is narrowed to excludeNarrowedType.
Por ejemplo:
from typing import assert_type, final, TypeIs class Parent: pass class Child(Parent): pass @final class Unrelated: pass def is_parent(val: object) -> TypeIs[Parent]: return isinstance(val, Parent) def run(arg: Child | Unrelated): if is_parent(arg): # Type of ``arg`` is narrowed to the intersection # of ``Parent`` and ``Child``, which is equivalent to # ``Child``. assert_type(arg, Child) else: # Type of ``arg`` is narrowed to exclude ``Parent``, # so only ``Unrelated`` is left. assert_type(arg, Unrelated)
The type inside
TypeIsmust be consistent with the type of the function’s argument; if it is not, static type checkers will raise an error. An incorrectly writtenTypeIsfunction can lead to unsound behavior in the type system; it is the user’s responsibility to write such functions in a type-safe manner.If a
TypeIsfunction is a class or instance method, then the type inTypeIsmaps to the type of the second parameter (afterclsorself).In short, the form
def foo(arg: TypeA) -> TypeIs[TypeB]: ..., means that iffoo(arg)returnsTrue, thenargis an instance ofTypeB, and if it returnsFalse, it is not an instance ofTypeB.TypeIsalso works with type variables. For more information, see PEP 742 (Narrowing types withTypeIs).Added in version 3.13.
- typing.TypeGuard¶
Special typing construct for marking user-defined type predicate functions.
Type predicate functions are user-defined functions that return whether their argument is an instance of a particular type.
TypeGuardworks similarly toTypeIs, but has subtly different effects on type checking behavior (see below).El uso de
-> TypeGuardle dice al validador 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.
TypeGuardtambién funciona con variables de tipo. Véase PEP 647 para más detalles.Por ejemplo:
def is_str_list(val: list[object]) -> TypeGuard[list[str]]: '''Determines whether all objects in the list are strings''' return all(isinstance(x, str) for x in val) def func1(val: list[object]): if is_str_list(val): # 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!")
TypeIsandTypeGuarddiffer in the following ways:TypeIsrequires the narrowed type to be a subtype of the input type, whileTypeGuarddoes not. The main reason is to allow for things like narrowinglist[object]tolist[str]even though the latter is not a subtype of the former, sincelistis invariant.When a
TypeGuardfunction returnsTrue, type checkers narrow the type of the variable to exactly theTypeGuardtype. When aTypeIsfunction returnsTrue, type checkers can infer a more precise type combining the previously known type of the variable with theTypeIstype. (Technically, this is known as an intersection type.)When a
TypeGuardfunction returnsFalse, type checkers cannot narrow the type of the variable at all. When aTypeIsfunction returnsFalse, type checkers can narrow the type of the variable to exclude theTypeIstype.
Added in version 3.10.
- typing.Unpack¶
Tipado para marcar conceptualmente un objeto como si hubiera sido desempaquetado.
For example, using the unpack operator
*on a type variable tuple is equivalent to usingUnpackto mark the type variable tuple as having been unpacked:Ts = TypeVarTuple('Ts') tup: tuple[*Ts] # Effectively does: tup: tuple[Unpack[Ts]]
De hecho,
Unpackse puede usar indistintamente con*en el contexto de los tipostyping.TypeVarTupleybuiltins.tuple. Es posible que veas queUnpackse usa explícitamente en versiones anteriores de Python, donde*no se podía usar en ciertos lugares:# In older versions of Python, TypeVarTuple and Unpack # are located in the `typing_extensions` backports package. from typing_extensions import TypeVarTuple, Unpack Ts = TypeVarTuple('Ts') tup: tuple[*Ts] # Syntax error on Python <= 3.10! tup: tuple[Unpack[Ts]] # Semantically equivalent, and backwards-compatible
Unpacktambién se puede usar junto contyping.TypedDictpara tipear**kwargsen una firma de función:from typing import TypedDict, Unpack class Movie(TypedDict): name: str year: int # This function expects two keyword arguments - `name` of type `str` # and `year` of type `int`. def foo(**kwargs: Unpack[Movie]): ...
Consulte PEP 692 para obtener más información sobre el uso de
Unpackpara tipear**kwargs.Added in version 3.11.
Creación de tipos genéricos y alias de tipos¶
Las siguientes clases no se deben utilizar directamente como anotaciones. Su finalidad es servir de bloques de construcción para crear tipos genéricos y alias de tipos.
Estos objetos se pueden crear mediante una sintaxis especial (type parameter lists y la declaración type). Para compatibilidad con Python 3.11 y versiones anteriores, también se pueden crear sin la sintaxis dedicada, como se documenta a continuación.
- class typing.Generic¶
Clase base abstracta para tipos genéricos.
Un tipo genérico normalmente se declara agregando una lista de parámetros de tipo después del nombre de la clase:
class Mapping[KT, VT]: def __getitem__(self, key: KT) -> VT: ... # Etc.
Esta clase hereda implícitamente de
Generic. La semántica de tiempo de ejecución de esta sintaxis se analiza en la Referencia del lenguaje.Entonces, esta clase se puede usar como sigue:
def lookup_name[X, Y](mapping: Mapping[X, Y], key: X, default: Y) -> Y: try: return mapping[key] except KeyError: return default
Aquí los corchetes después del nombre de la función indican una función genérica.
Para compatibilidad con versiones anteriores, las clases genéricas también se pueden declarar heredando explícitamente de
Generic. En este caso, los parámetros de tipo se deben declarar por separado:KT = TypeVar('KT') VT = TypeVar('VT') class Mapping(Generic[KT, VT]): def __getitem__(self, key: KT) -> VT: ... # Etc.
- class typing.TypeVar(name, *constraints, bound=None, covariant=False, contravariant=False, infer_variance=False, default=typing.NoDefault)¶
Variable de tipo.
La forma preferida de construir una variable de tipo es a través de la sintaxis dedicada para funciones genéricas, clases genéricas y alias de tipo genérico:
class Sequence[T]: # T is a TypeVar ...
This syntax can also be used to create bounded and constrained type variables:
class StrSequence[S: str]: # S is a TypeVar with a `str` upper bound; ... # we can say that S is "bounded by `str`" class StrOrBytesSequence[A: (str, bytes)]: # A is a TypeVar constrained to str or bytes ...
Sin embargo, si se desea, también se pueden construir manualmente variables de tipo reutilizables, de la siguiente manera:
T = TypeVar('T') # Can be anything S = TypeVar('S', bound=str) # Can be any subtype of str A = TypeVar('A', str, bytes) # Must be exactly str or bytes
Las variables de tipo existen principalmente para el beneficio de los validadores de tipos estáticos. Sirven como parámetros para tipos genéricos, así como para definiciones de alias de tipo y funciones genéricas. Consulte
Genericpara obtener más información sobre tipos genéricos. Las funciones genéricas funcionan de la siguiente manera:def repeat[T](x: T, n: int) -> Sequence[T]: """Return a list containing n references to x.""" return [x]*n def print_capitalized[S: str](x: S) -> S: """Print x capitalized, and return x.""" print(x.capitalize()) return x def concatenate[A: (str, bytes)](x: A, y: A) -> A: """Add two strings or bytes objects together.""" return x + y
Note that type variables can be bounded, constrained, or neither, but cannot be both bounded and constrained.
La varianza de las variables de tipo es inferida por los validadores de tipo cuando se crean a través de la sintáxis de parámetros de tipo o cuando se pasa
infer_variance=True. Las variables de tipo creadas manualmente se pueden marcar explícitamente como covariantes o contravariantes al pasarcovariant=Trueocontravariant=True. De manera predeterminada, las variables de tipo creadas manualmente son invariantes. Consulte PEP 484 y PEP 695 para obtener más detalles.Bounded type variables and constrained type variables have different semantics in several important ways. Using a bounded type variable means that the
TypeVarwill be solved using the most specific type possible:x = print_capitalized('a string') reveal_type(x) # revealed type is str class StringSubclass(str): pass y = print_capitalized(StringSubclass('another string')) reveal_type(y) # revealed type is StringSubclass z = print_capitalized(45) # error: int is not a subtype of str
The upper bound of a type variable can be a concrete type, abstract type (ABC or Protocol), or even a union of types:
# Can be anything with an __abs__ method def print_abs[T: SupportsAbs](arg: T) -> None: print("Absolute value:", abs(arg)) U = TypeVar('U', bound=str|bytes) # Can be any subtype of the union str|bytes V = TypeVar('V', bound=SupportsAbs) # Can be anything with an __abs__ method
Sin embargo, usar una variable de tipo constrained significa que la
TypeVarsólo podrá ser determinada como exactamente una de las restricciones dadas:a = concatenate('one', 'two') reveal_type(a) # revealed type is str b = concatenate(StringSubclass('one'), StringSubclass('two')) reveal_type(b) # revealed type is str, despite StringSubclass being passed in c = concatenate('one', b'two') # error: type variable 'A' can be either str or bytes in a function call, but not both
En tiempo de ejecución,
isinstance(x, T)lanzaráTypeError.- __name__¶
El nombre de la variable de tipo.
- __covariant__¶
Si la variable de tipo ha sido marcado explícitamente como covariante.
- __contravariant__¶
Si la variable de tipo ha sido marcado explícitamente como covariante.
- __infer_variance__¶
Si los validadores de tipo deben inferir la variación de la variable de tipo.
Added in version 3.12.
- __bound__¶
The upper bound of the type variable, if any.
Distinto en la versión 3.12: Para las variables de tipo creadas a través de sintáxis de parámetros de tipo, el límite se evalúa solo cuando se accede al atributo, no cuando se crea la variable de tipo (consulte Evaluación perezosa).
- __constraints__¶
Una tupla que contiene las restricciones de la variable de tipo, si las hay.
Distinto en la versión 3.12: Para las variables de tipo creadas a través de la sintáxis de parámetros de tipo, las restricciones se evalúan solo cuando se accede al atributo, no cuando se crea la variable de tipo (consulte Evaluación perezosa).
- __default__¶
The default value of the type variable, or
typing.NoDefaultif it has no default.Added in version 3.13.
- has_default()¶
Return whether or not the type variable has a default value. This is equivalent to checking whether
__default__is not thetyping.NoDefaultsingleton, except that it does not force evaluation of the lazily evaluated default value.Added in version 3.13.
Distinto en la versión 3.12: Ahora es posible declarar variables de tipo utilizando la sintaxis de parámetros de tipo introducida por PEP 695. Se agregó el parámetro
infer_variance.Distinto en la versión 3.13: Support for default values was added.
- class typing.TypeVarTuple(name, *, default=typing.NoDefault)¶
Type variable tuple. A specialized form of type variable that enables variadic generics.
Las tuplas de variables de tipo se pueden declarar en listas de parámetros de tipo usando un solo asterisco (
*) antes del nombre:def move_first_element_to_last[T, *Ts](tup: tuple[T, *Ts]) -> tuple[*Ts, T]: return (*tup[1:], tup[0])
O invocando explícitamente el constructor
TypeVarTuple:T = TypeVar("T") Ts = TypeVarTuple("Ts") def move_first_element_to_last(tup: tuple[T, *Ts]) -> tuple[*Ts, T]: return (*tup[1:], tup[0])
Una variable de tipo normal permite parametrizar con un solo tipo. Una tupla de variables de tipo, en contraste, permite la parametrización con un número arbitrario de tipos, al actuar como un número arbitrario de variables de tipo envueltas en una tupla. Por ejemplo:
# T is bound to int, Ts is bound to () # Return value is (1,), which has type tuple[int] move_first_element_to_last(tup=(1,)) # T is bound to int, Ts is bound to (str,) # Return value is ('spam', 1), which has type tuple[str, int] move_first_element_to_last(tup=(1, 'spam')) # T is bound to int, Ts is bound to (str, float) # Return value is ('spam', 3.0, 1), which has type tuple[str, float, int] move_first_element_to_last(tup=(1, 'spam', 3.0)) # This fails to type check (and fails at runtime) # because tuple[()] is not compatible with tuple[T, *Ts] # (at least one element is required) move_first_element_to_last(tup=())
Nótese el uso del operador de desempaquetado
*entuple[T, *Ts]. Conceptualmente, puede pensarse enTscomo 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 descomprimirse. Esto ayuda a distinguir las tuplas de variables de tipo, de las variables de tipo normales:
x: Ts # Not valid x: tuple[Ts] # Not valid x: tuple[*Ts] # The correct way to do it
Las tuplas de variables de tipo pueden ser utilizadas en los mismos contextos que las variables de tipo normales. Por ejemplo en definiciones de clases, argumentos y tipos de retorno:
class Array[*Shape]: def __getitem__(self, key: tuple[*Shape]) -> float: ... def __abs__(self) -> "Array[*Shape]": ... def get_shape(self) -> tuple[*Shape]: ...
Las tuplas de variables de tipo se pueden combinar sin problemas con variables de tipo normales:
class Array[DType, *Shape]: # This is fine pass class Array2[*Shape, DType]: # This would also be fine pass class Height: ... class Width: ... float_array_1d: Array[float, Height] = Array() # Totally fine int_array_2d: Array[int, Height, Width] = Array() # Yup, fine too
Sin embargo, nótese que en una determinada lista de argumentos de tipo o de parámetros de tipo puede haber como máximo una tupla de variables de tipo:
x: tuple[*Ts, *Ts] # Not valid class Array[*Shape, *Shape]: # Not valid pass
Finalmente, una tupla de variables de tipo desempaquetada puede ser utilizada como la anotación de tipo de
*args:def call_soon[*Ts]( callback: Callable[[*Ts], None], *args: *Ts ) -> None: ... callback(*args)
En contraste con las anotaciones no-desempaquetadas de
*args, por ej.*args: int, que especificaría que todos los argumentos sonint-*args: *Tspermite referenciar los tipos de los argumentos individuales en*args. Aquí, ésto permite asegurarse de que los tipos de los*argsque son pasados acall_sooncalcen con los tipos de los argumentos (posicionales) decallback.Véase PEP 646 para obtener más detalles sobre las tuplas de variables de tipo.
- __name__¶
El nombre de la tupla de variables de tipo.
- __default__¶
The default value of the type variable tuple, or
typing.NoDefaultif it has no default.Added in version 3.13.
- has_default()¶
Return whether or not the type variable tuple has a default value. This is equivalent to checking whether
__default__is not thetyping.NoDefaultsingleton, except that it does not force evaluation of the lazily evaluated default value.Added in version 3.13.
Added in version 3.11.
Distinto en la versión 3.12: Ahora es posible declarar tuplas de variables de tipo utilizando la sintaxis de parámetros de tipo introducida por PEP 695.
Distinto en la versión 3.13: Support for default values was added.
- class typing.ParamSpec(name, *, bound=None, covariant=False, contravariant=False, default=typing.NoDefault)¶
Parameter specification variable. A specialized version of type variables.
En las listas de parámetros de tipo, las especificaciones de parámetros se pueden declarar con dos asteriscos (
**):type IntFunc[**P] = Callable[P, int]
Para compatibilidad con Python 3.11 y versiones anteriores, los objetos
ParamSpectambién se pueden crear de la siguiente manera:P = ParamSpec('P')
Las variables de especificación de parámetros existen principalmente para el beneficio de los validadores de tipo estático. Se utilizan para reenviar los tipos de parámetros de un invocable a otro invocable, un patrón que se encuentra comúnmente en funciones y decoradores de orden superior. Solo son válidos cuando se utilizan en
Concatenate, o como primer argumento deCallable, o como parámetros para genéricos definidos por el usuario. ConsulteGenericpara 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_loggingpara registrar llamadas a funciones. La variable de especificación de parámetros le dice al validador de tipo que el invocable pasado al decorador y el nuevo invocable retornado por él tienen parámetros de tipo interdependientes:from collections.abc import Callable import logging def add_logging[T, **P](f: Callable[P, T]) -> Callable[P, T]: '''A type-safe decorator to add logging to a function.''' def inner(*args: P.args, **kwargs: P.kwargs) -> T: logging.info(f'{f.__name__} was called') return f(*args, **kwargs) return inner @add_logging def add_two(x: float, y: float) -> float: '''Add two numbers together.''' return x + y
Without
ParamSpec, the simplest way to annotate this previously was to use aTypeVarwith upper boundCallable[..., Any]. However this causes two problems:El validador de tipo no puede verificar la función
innerporque*argsy**kwargsdeben escribirseAny.Es posible que se requiera
cast()en el cuerpo del decoradoradd_loggingal retornar la funcióninner, o se debe indicar al validador de tipo estático que ignore elreturn inner.
- args¶
- kwargs¶
Dado que
ParamSpeccaptura tanto parámetros posicionales como de palabras clave,P.argsyP.kwargsse pueden utilizar para dividir unParamSpecen sus componentes.P.argsrepresenta la tupla de parámetros posicionales en una llamada determinada y solo debe usarse para anotar*args.P.kwargsrepresenta 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.argsyP.kwargsson instancias respectivamente deParamSpecArgsyParamSpecKwargs.
- __name__¶
El nombre de la especificación del parámetro.
- __default__¶
The default value of the parameter specification, or
typing.NoDefaultif it has no default.Added in version 3.13.
- has_default()¶
Return whether or not the parameter specification has a default value. This is equivalent to checking whether
__default__is not thetyping.NoDefaultsingleton, except that it does not force evaluation of the lazily evaluated default value.Added in version 3.13.
Las variables de especificación de parámetros creadas con
covariant=Trueocontravariant=Truese 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.Added in version 3.10.
Distinto en la versión 3.12: Las especificaciones de parámetros ahora se pueden declarar utilizando la sintaxis de parámetros de tipo introducida por PEP 695.
Distinto en la versión 3.13: Support for default values was added.
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
ParamSpecyConcatenate)
- typing.ParamSpecArgs¶
- typing.ParamSpecKwargs¶
Argumentos y atributos de argumentos de palabras clave de un
ParamSpec. El atributoP.argsde unParamSpeces una instancia deParamSpecArgsyP.kwargses una instancia deParamSpecKwargs. Están pensados para la introspección en tiempo de ejecución y no tienen un significado especial para los validadores de tipo estático.Llamar a
get_origin()en cualquiera de estos objetos retornará elParamSpecoriginal:>>> from typing import ParamSpec, get_origin >>> P = ParamSpec("P") >>> get_origin(P.args) is P True >>> get_origin(P.kwargs) is P True
Added in version 3.10.
- class typing.TypeAliasType(name, value, *, type_params=())¶
El tipo de alias de tipo creado a través de la declaración
type.Por ejemplo:
>>> type Alias = int >>> type(Alias) <class 'typing.TypeAliasType'>
Added in version 3.12.
- __name__¶
El nombre del alias de tipo:
>>> type Alias = int >>> Alias.__name__ 'Alias'
- __module__¶
El módulo en el que se definió el alias de tipo:
>>> type Alias = int >>> Alias.__module__ '__main__'
- __type_params__¶
Los parámetros de tipo del alias de tipo, o una tupla vacía si el alias no es genérico:
>>> type ListOrSet[T] = list[T] | set[T] >>> ListOrSet.__type_params__ (T,) >>> type NotGeneric = int >>> NotGeneric.__type_params__ ()
- __value__¶
El valor del alias de tipo. Se evalúa de forma diferida, por lo que los nombres utilizados en la definición del alias no se resuelven hasta que se accede al atributo
__value__:>>> type Mutually = Recursive >>> type Recursive = Mutually >>> Mutually Mutually >>> Recursive Recursive >>> Mutually.__value__ Recursive >>> Recursive.__value__ Mutually
Otras directivas especiales¶
Estas funciones y clases no se deben utilizar directamente como anotaciones. Su finalidad es servir de bloques de construcción para crear y declarar tipos.
- class typing.NamedTuple¶
Versión para anotación de tipos de
collections.namedtuple().Uso:
class Employee(NamedTuple): name: str id: int
Esto es equivalente a:
Employee = collections.namedtuple('Employee', ['name', 'id'])
Para proporcionar a un campo un valor por defecto se puede asignar en el cuerpo de la clase:
class Employee(NamedTuple): name: str id: int = 3 employee = Employee('Guido') assert employee.id == 3
Los campos con un valor por defecto deben ir después de los campos sin valor por defecto.
La clase resultante tiene un atributo extra
__annotations__que proporciona un diccionario que mapea el nombre de los campos con sus respectivos tipos. (Los nombres de los campos están en el atributo_fieldsy sus valores por defecto en el atributo_field_defaults, ambos parte de la APInamedtuple().)Las subclases de
NamedTupletambié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
NamedTuplepueden ser genéricas:class Group[T](NamedTuple): key: T group: list[T]
Uso retrocompatible:
# For creating a generic NamedTuple on Python 3.11 T = TypeVar("T") class Group(NamedTuple, Generic[T]): key: T group: list[T] # A functional syntax is also supported Employee = NamedTuple('Employee', [('name', str), ('id', int)])
Distinto en la versión 3.6: Soporte añadido para la sintaxis de anotación de variables propuesto en PEP 526.
Distinto en la versión 3.6.1: Soporte añadido para valores por defecto, métodos y docstrings.
Distinto en la versión 3.8: Los atributos
_field_typesy__annotations__son simples diccionarios en vez de instancias deOrderedDict.Distinto en la versión 3.9: Se remueve el atributo
_field_typesen 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.
Deprecated since version 3.13, will be removed in version 3.15: The undocumented keyword argument syntax for creating NamedTuple classes (
NT = NamedTuple("NT", x=int)) is deprecated, and will be disallowed in 3.15. Use the class-based syntax or the functional syntax instead.Deprecated since version 3.13, will be removed in version 3.15: When using the functional syntax to create a NamedTuple class, failing to pass a value to the “fields” parameter (
NT = NamedTuple("NT")) is deprecated. PassingNoneto the “fields” parameter (NT = NamedTuple("NT", None)) is also deprecated. Both will be disallowed in Python 3.15. To create a NamedTuple class with 0 fields, useclass NT(NamedTuple): passorNT = NamedTuple("NT", []).
- class typing.NewType(name, tp)¶
Clase auxiliar para crear tipos distintos con bajo consumo de recursos.
Un validador de tipos considera que un
NewTypees un tipo distinto. Sin embargo, en tiempo de ejecución, llamar a unNewTypedevuelve su argumento sin cambios.Uso:
UserId = NewType('UserId', int) # Declare the NewType "UserId" first_user = UserId(1) # "UserId" returns the argument unchanged at runtime
- __module__¶
El módulo en el que se define el nuevo tipo.
- __name__¶
El nombre del nuevo tipo.
- __supertype__¶
El tipo en el que se basa el nuevo tipo.
Added in version 3.5.2.
Distinto en la versión 3.10:
NewTypees ahora una clase en lugar de una función.
- class typing.Protocol(Generic)¶
Clase base para clases de protocolo.
Las clases de protocolo se definen así:
class Proto(Protocol): def meth(self) -> int: ...
Tales clases son usadas principalmente con validadores estáticos de tipos que detectan subtipado estructural (duck-typing estático), por ejemplo:
class C: def meth(self) -> int: return 0 def func(x: Proto) -> int: return x.meth() func(C()) # Passes static type check
See PEP 544 for more details. Protocol classes decorated with
runtime_checkable()(described later) act as simple-minded runtime protocols that check only the presence of given attributes, ignoring their type signatures. Protocol classes without this decorator cannot be used as the second argument toisinstance()orissubclass().Las clases protocolo pueden ser genéricas, por ejemplo:
class GenProto[T](Protocol): def meth(self) -> T: ...
En el código que necesita ser compatible con Python 3.11 o anterior, los protocolos genéricos se pueden escribir de la siguiente manera:
T = TypeVar("T") class GenProto(Protocol[T]): def meth(self) -> T: ...
Added in version 3.8.
- @typing.runtime_checkable¶
Marca una clase protocolo como aplicable en tiempo de ejecución (lo convierte en un runtime protocol).
Such a protocol can be used with
isinstance()andissubclass(). This allows a simple-minded structural check, very similar to «one trick ponies» incollections.abcsuch asIterable. For example:@runtime_checkable class Closable(Protocol): def close(self): ... assert isinstance(open('/some/file'), Closable) @runtime_checkable class Named(Protocol): name: str import threading assert isinstance(threading.Thread(name='Bob'), Named)
This decorator raises
TypeErrorwhen applied to a non-protocol class.Nota
runtime_checkable()comprobará únicamente la presencia de los métodos o atributos requeridos, no sus firmas de tipo o tipos. Por ejemplo,ssl.SSLObjectes una clase, por lo tanto, pasa una comprobaciónissubclass()contra Callable. Sin embargo, el métodossl.SSLObject.__init__existe únicamente para generar unTypeErrorcon un mensaje más informativo, por lo que es imposible llamar (instanciar)ssl.SSLObject.Nota
Una verificación
isinstance()contra un protocolo comprobable en tiempo de ejecución puede ser sorprendentemente lenta en comparación con una verificaciónisinstance()contra una clase que no es de protocolo. Considere utilizar expresiones alternativas como llamadashasattr()para comprobaciones estructurales en código sensible al rendimiento.Added in version 3.8.
Distinto en la versión 3.12: La implementación interna de las comprobaciones de
isinstance()con protocolos que se pueden comprobar en tiempo de ejecución ahora utilizainspect.getattr_static()para buscar atributos (anteriormente, se utilizabahasattr()). Como resultado, algunos objetos que solían considerarse instancias de un protocolo que se podía comprobar en tiempo de ejecución ya no se consideran instancias de ese protocolo en Python 3.12+, y viceversa. Es poco probable que la mayoría de los usuarios se vean afectados por este cambio.Distinto en la versión 3.12: Los miembros de un protocolo que se pueden comprobar en tiempo de ejecución ahora se consideran «congelados» en tiempo de ejecución tan pronto como se crea la clase. La aplicación de parches de atributos en un protocolo que se puede comprobar en tiempo de ejecución seguirá funcionando, pero no tendrá ningún impacto en las comprobaciones de
isinstance()que comparan objetos con el protocolo. Consulte «¿Qué hay de nuevo en Python 3.12» para obtener más detalles.
- class typing.TypedDict(dict)¶
Es una construcción especial para añadir indicadores de tipo a un diccionario. En tiempo de ejecución es un
dictsimple.TypedDictcrea 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
TypedDictis by using function-call syntax. The second argument must be a literaldict: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, or when key names must not be mangled like regular private names:
# raises SyntaxError class Point2D(TypedDict): in: int # 'in' is a keyword x-y: int # name with hyphens class Definition(TypedDict): __schema: str # mangled to `_Definition__schema` # OK, functional syntax Point2D = TypedDict('Point2D', {'in': int, 'x-y': int}) Definition = TypedDict('Definition', {'__schema': str}) # not mangled
De forma predeterminada, todas las llaves deben estar presentes en un
TypedDict. Es posible marcar llaves individuales como no requeridas 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
TypedDictque 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
Falseen 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
TypedDictPoint2Dpuede tener cualquiera de las llaves omitidas. Solo se espera que un validador de tipo admita unFalseliteral oTruecomo valor del argumentototal.Truees el predeterminado y hace que todos los elementos definidos en el cuerpo de la clase sean obligatorios.Las llaves individuales de un
TypedDicttotal=Falsepueden 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
TypedDictherede de uno o más tiposTypedDictusando la sintaxis de clase. Uso:class Point3D(Point2D): z: int
Point3Dtiene tres elementos:x,yyz. Lo que es equivalente a la siguiente definición:class Point3D(TypedDict): x: int y: int z: int
Un
TypedDictno 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
Un
TypedDictpuede ser genérico:class Group[T](TypedDict): key: T group: list[T]
Para crear un
TypedDictgenérico que sea compatible con Python 3.11 o anterior, herede deGenericexplícitamente:T = TypeVar("T") class Group(TypedDict, Generic[T]): key: T group: list[T]
A
TypedDictcan be introspected via annotations dicts (see Prácticas recomendadas para las anotaciones for more information on annotations best practices),__total__,__required_keys__, and__optional_keys__.- __total__¶
Point2D.__total__proporciona el valor del 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
This attribute reflects only the value of the
totalargument to the currentTypedDictclass, not whether the class is semantically total. For example, aTypedDictwith__total__set toTruemay have keys marked withNotRequired, or it may inherit from anotherTypedDictwithtotal=False. Therefore, it is generally better to use__required_keys__and__optional_keys__for introspection.
- __required_keys__¶
Added in version 3.9.
- __optional_keys__¶
Point2D.__required_keys__yPoint2D.__optional_keys__retornan objetos de la clasefrozenset, que contienen las llaves requeridas y no requeridas, respectivamente.Las llaves marcadas con
Requiredsiempre aparecerán en__required_keys__y las llaves marcadas conNotRequiredsiempre aparecerán en__optional_keys__.Para compatibilidad con versiones anteriores de Python 3.10, también es posible usar la herencia para declarar claves obligatorias y no obligatorias en el mismo
TypedDict. Esto se hace declarando unTypedDictcon un valor para el argumentototaly luego heredando de él en otroTypedDictcon un valor diferente 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
Added in version 3.9.
Nota
If
from __future__ import annotationsis used or if annotations are given as strings, annotations are not evaluated when theTypedDictis defined. Therefore, the runtime introspection that__required_keys__and__optional_keys__rely on may not work properly, and the values of the attributes may be incorrect.
Support for
ReadOnlyis reflected in the following attributes:- __readonly_keys__¶
A
frozensetcontaining the names of all read-only keys. Keys are read-only if they carry theReadOnlyqualifier.Added in version 3.13.
- __mutable_keys__¶
A
frozensetcontaining the names of all mutable keys. Keys are mutable if they do not carry theReadOnlyqualifier.Added in version 3.13.
Véase PEP 589 para más ejemplos y reglas detalladas del uso de
TypedDict.Added in version 3.8.
Distinto en la versión 3.11: Se agrega soporte para marcar llaves individuales como
RequiredoNotRequired. Véase PEP 655.Distinto en la versión 3.11: Se agrega soporte para
TypedDictgenéricos.Distinto en la versión 3.13: Removed support for the keyword-argument method of creating
TypedDicts.Distinto en la versión 3.13: Support for the
ReadOnlyqualifier was added.Deprecated since version 3.13, will be removed in version 3.15: When using the functional syntax to create a TypedDict class, failing to pass a value to the “fields” parameter (
TD = TypedDict("TD")) is deprecated. PassingNoneto the “fields” parameter (TD = TypedDict("TD", None)) is also deprecated. Both will be disallowed in Python 3.15. To create a TypedDict class with 0 fields, useclass TD(TypedDict): passorTD = TypedDict("TD", {}).
Protocolos¶
The following protocols are provided by the typing module. All are decorated
with @runtime_checkable.
- class typing.SupportsAbs¶
Una ABC con un método abstracto
__abs__que es covariante en su tipo retornado.
- class typing.SupportsBytes¶
Una ABC con un método abstracto
__bytes__.
- class typing.SupportsComplex¶
Una ABC con un método abstracto
__complex__.
- class typing.SupportsFloat¶
Una ABC con un método abstracto
__float__.
- class typing.SupportsIndex¶
Una ABC con un método abstracto
__index__.Added in version 3.8.
- class typing.SupportsInt¶
Una ABC con un método abstracto
__int__.
- class typing.SupportsRound¶
Una ABC con un método abstracto
__round__que es covariantes en su tipo retornado.
ABC para trabajar con IO¶
Funciones y decoradores¶
- typing.cast(typ, val)¶
Convertir un valor a un tipo.
Esto retorna el valor sin modificar. Para el validador de tipos esto indica que el valor de retorno tiene el tipo señalado pero, de manera intencionada, no se comprobará en tiempo de ejecución (para maximizar la velocidad).
- typing.assert_type(val, typ, /)¶
Solicitar a un validador de tipos que confirme que val tiene typ por tipo inferido.
En tiempo de ejecución esto no hace nada: devuelve el primer argumento sin cambios, sin verificaciones ni efectos secundarios, sin importar el tipo real del argumento.
Cuando un validador de tipo estático encuentra una llamada a
assert_type(), emite un error si el valor no es del tipo especificado:def greet(name: str) -> None: assert_type(name, str) # OK, inferred type of `name` is `str` assert_type(name, int) # type checker error
Esta función es útil para asegurarse de que la comprensión que el validador de tipos tiene sobre un script está alineada con las intenciones de le desarrolladores:
def complex_function(arg: object): # Do some complex type-narrowing logic, # after which we hope the inferred type will be `int` ... # Test whether the type checker correctly understands our function assert_type(arg, int)
Added in version 3.11.
- typing.assert_never(arg, /)¶
Solicitar a un validador estático de tipos confirmar que una línea de código no es alcanzable.
Por ejemplo:
def int_or_str(arg: int | str) -> None: match arg: case int(): print("It's an int") case str(): print("It's a str") case _ as unreachable: assert_never(unreachable)
Aquí, las anotaciones permiten al validador de tipos inferir que el último caso nunca puede ejecutarse, porque
arges uninto unstr, y ambas opciones están cubiertas por los casos anteriores.Si un validador de tipos encuentra que una llamada a
assert_never()es alcanzable, emitirá un error. Por ejemplo, si la anotación de tipo paraargfuese en cambioint | str | float, el validador de tipos emitiría un error que indicaría queunreachablees de tipofloat. Para que una llamada aassert_neverpase la verificación de tipos, el tipo inferido del argumento pasado debe ser el tipo inferior,Never, y nada más.En tiempo de ejecución, ésto lanza una excepción cuando es llamado.
Ver también
Unreachable Code and Exhaustiveness Checking has more information about exhaustiveness checking with static typing.
Added in version 3.11.
- typing.reveal_type(obj, /)¶
Ask a static type checker to reveal the inferred type of an expression.
When a static type checker encounters a call to this function, it emits a diagnostic with the inferred type of the argument. For example:
x: int = 1 reveal_type(x) # Revealed type is "builtins.int"
Ésto puede ser de utilidad cuando se desea debuguear cómo tu validador de tipos maneja una pieza particular de código.
At runtime, this function prints the runtime type of its argument to
sys.stderrand returns the argument unchanged (allowing the call to be used within an expression):x = reveal_type(1) # prints "Runtime type is int" print(x) # prints "1"
Note that the runtime type may be different from (more or less specific than) the type statically inferred by a type checker.
Most type checkers support
reveal_type()anywhere, even if the name is not imported fromtyping. Importing the name fromtyping, however, allows your code to run without runtime errors and communicates intent more clearly.Added in version 3.11.
- @typing.dataclass_transform(*, eq_default=True, order_default=False, kw_only_default=False, frozen_default=False, field_specifiers=(), **kwargs)¶
Decorador para marcar un objeto como si proporcionara un comportamiento similar a
dataclass.dataclass_transformse puede utilizar para decorar una clase, metaclase o una función que sea en sí misma un decorador. La presencia de@dataclass_transform()le indica al validador de tipos estáticos que el objeto decorado realiza una «magia» en tiempo de ejecución que transforma una clase de manera similar a@dataclasses.dataclass.Ejemplo de uso con una función decoradora:
@dataclass_transform() def create_model[T](cls: type[T]) -> type[T]: ... return cls @create_model class CustomerModel: id: int name: str
En una clase base:
@dataclass_transform() class ModelBase: ... class CustomerModel(ModelBase): id: int name: str
En una metaclase:
@dataclass_transform() class ModelMeta(type): ... class ModelBase(metaclass=ModelMeta): ... class CustomerModel(ModelBase): id: int name: str
Las clases
CustomerModeldefinidas 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 aceptanidyname.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 (TrueoFalse).Es posible utilizar los argumentos del decorador
dataclass_transformpara personalizar los comportamientos por defecto de la clase, metaclase o función decorada:- Parámetros:
eq_default (bool) – Indica si se asume que el parámetro
eqesTrueoFalsesi el llamador lo omite. El valor predeterminado esTrue.order_default (bool) – Indica si se asume que el parámetro
orderesTrueoFalsesi el llamador lo omite. El valor predeterminado esFalse.kw_only_default (bool) – Indica si se asume que el parámetro
kw_onlyesTrueoFalsesi el llamador lo omite. El valor predeterminado esFalse.frozen_default (bool) – Indica si se asume que el parámetro
frozenesTrueoFalsesi el llamador lo omite. El valor predeterminado esFalse. .. Agregado en la versión:: 3.12field_specifiers (tuple[Callable[..., Any], ...]) – Especifica una lista estática de clases o funciones admitidas que describen campos, parecido con
dataclasses.field(). El valor predeterminado es().**kwargs (Any) – Es posible pasar arbitrariamente otros argumentos nombrados para permitir posibles extensiones futuras.
Los validadores de tipos reconocen los siguientes parámetros opcionales en los especificadores de campo:
Parámetros reconocidos para especificadores de campo¶ Nombre del parámetro
Descripción
initIndica si el campo debe incluirse en el método
__init__sintetizado. Si no se especifica, el valor predeterminado deinitesTrue.defaultProporciona el valor predeterminado para el campo.
default_factoryProporciona una retrollamada en tiempo de ejecución que devuelve el valor predeterminado del campo. Si no se especifican
defaultnidefault_factory, se supone que el campo no tiene un valor predeterminado y se le debe proporcionar un valor cuando se cree una instancia de la clase.factoryUn alias para el parámetro
default_factoryen los especificadores de campo.kw_onlyIndica si el campo debe marcarse como solo para palabras clave. Si es
True, el campo será solo para palabras clave. Si esFalse, no será solo para palabras clave. Si no se especifica, se utilizará el valor del parámetrokw_onlyen el objeto decorado condataclass_transform, o si no se especifica, se utilizará el valor dekw_only_defaultendataclass_transform.aliasProporciona un nombre alternativo para el campo. Este nombre alternativo se utiliza en el método sintetizado
__init__.En tiempo de ejecución, este decorador registra sus argumentos en el atributo
__dataclass_transform__del objeto decorado. No tiene otro efecto en tiempo de ejecución.Véase PEP 681 para más detalle.
Added in version 3.11.
- @typing.overload¶
Decorador para crear funciones y métodos sobrecargados.
El decorador
@overloadpermite describir funciones y métodos que admiten múltiples combinaciones diferentes de tipos de argumentos. Una serie de definiciones decoradas con@overloaddebe ir seguida de exactamente una definición que no esté decorada con@overload(para la misma función o método).Las definiciones decoradas con
@overloadson solo para beneficio del validador de tipos, ya que serán sobrescritas por la definición no decorada con@overload. Mientras tanto, la definición no decorada con@overloadse usará en tiempo de ejecución, pero el validador de tipos debe ignorarla. En tiempo de ejecución, llamar a una función decorada con@overloaddirectamente generaráNotImplementedError.Un ejemplo de sobrecarga que proporciona un tipo más preciso que el que se puede expresar mediante una unión o una variable de tipo:
@overload def process(response: None) -> None: ... @overload def process(response: int) -> tuple[int, str]: ... @overload def process(response: bytes) -> str: ... def process(response): ... # actual implementation goes here
Véase PEP 484 para más detalle y comparación con otras semánticas de tipado.
Distinto en la versión 3.11: Ahora es posible introspectar en tiempo de ejecución las funciones sobrecargadas utilizando
get_overloads().
- typing.get_overloads(func)¶
Devuelve una secuencia de definiciones decoradas con
@overloadpara func.func es el objeto de función para la implementación de la función sobrecargada. Por ejemplo, dada la definición de
processen la documentación de@overload,get_overloads(process)devolverá una secuencia de tres objetos de función para las tres sobrecargas definidas. Si se llama en una función sin sobrecargas,get_overloads()devuelve una secuencia vacía.get_overloads()puede ser utilizada para introspectar en tiempo de ejecución una función sobrecargada.Added in version 3.11.
- typing.clear_overloads()¶
Borra todas las sobrecargas registradas en el registro interno.
Esto se puede utilizar para recuperar la memoria utilizada por el registro.
Added in version 3.11.
- @typing.final¶
Decorador para indicar métodos finales y clases finales.
Decorar un método con
@finalindica a un validador de tipos que el método no se puede anular en una subclase. Decorar una clase con@finalindica que no se puede subclasificar.Por ejemplo:
class Base: @final def done(self) -> None: ... class Sub(Base): def done(self) -> None: # Error reported by type checker ... @final class Leaf: ... class Other(Leaf): # Error reported by type checker ...
No hay comprobación en tiempo de ejecución para estas propiedades. Véase PEP 591 para más detalles.
Added in version 3.8.
Distinto en la versión 3.11: El decorador intentará ahora establecer un atributo
__final__comoTrueen el objeto decorado. Por lo tanto, se puede utilizar una comprobación comoif getattr(obj, “__final__”, False)en tiempo de ejecución para determinar si un objetoobjse ha marcado como final. Si el objeto decorado no admite la configuración de atributos, el decorador devuelve el objeto sin cambios sin lanzar una excepción.
- @typing.no_type_check¶
Un decorador para indicar que las anotaciones no deben ser comprobadas como indicadores de tipo.
Esto funciona como un decorator (decorador) de clase o función. Con una clase, se aplica recursivamente a todos los métodos y clases definidos en esa clase (pero no a los métodos definidos en sus superclases o subclases). Los validadores de tipos ignorarán todas las anotaciones en una función o clase con este decorador.
@no_type_checkmuta el objeto decorado en su lugar.
- @typing.no_type_check_decorator¶
Decorador para dar a otro decorador el efecto
no_type_check().Esto hace que el decorador decorado añada el efecto de
no_type_check()a la función decorada.Deprecated since version 3.13, will be removed in version 3.15: No type checker ever added support for
@no_type_check_decorator. It is therefore deprecated, and will be removed in Python 3.15.
- @typing.override¶
Decorador para indicar que un método en una subclase está destinado a anular un método o atributo en una superclase.
Los validadores de tipos deberían emitir un error si un método decorado con
@overrideno anula nada. Esto ayuda a evitar errores que pueden ocurrir cuando se modifica una clase base sin un cambio equivalente en una clase secundaria.Por ejemplo:
class Base: def log_status(self) -> None: ... class Sub(Base): @override def log_status(self) -> None: # Okay: overrides Base.log_status ... @override def done(self) -> None: # Error reported by type checker ...
No hay ninguna comprobación en tiempo de ejecución de esta propiedad.
El decorador intentará establecer un atributo
__override__enTrueen el objeto decorado. Por lo tanto, una comprobación comoif getattr(obj, “__override__”, False)se puede utilizar en tiempo de ejecución para determinar si un objetoobjha sido marcado como anulado. Si el objeto decorado no admite la configuración de atributos, el decorador devuelve el objeto sin cambios sin generar una excepción.Vea PEP 681 para más información.
Added in version 3.12.
- @typing.type_check_only¶
Decorador para marcar una clase o función como no disponible en tiempo de ejecución.
Este decorador no está disponible en tiempo de ejecución. Existe principalmente para marcar clases que se definen en archivos stub para cuando una implementación retorna una instancia de una clase privada:
@type_check_only class Response: # private or not available at runtime code: int def get_header(self, name: str) -> str: ... def fetch_response() -> Response: ...
Nótese que no se recomienda retornar instancias de clases privadas. Normalmente es preferible convertirlas en clases públicas.
Ayudas de introspección¶
- typing.get_type_hints(obj, globalns=None, localns=None, include_extras=False)¶
Retorna un diccionario que contiene indicaciones de tipo para una función, método, módulo o objeto clase.
This is often the same as
obj.__annotations__, but this function makes the following changes to the annotations dictionary:Forward references encoded as string literals or
ForwardRefobjects are handled by evaluating them in globalns, localns, and (where applicable) obj’s type parameter namespace. If globalns or localns is not given, appropriate namespace dictionaries are inferred from obj.Noneis replaced withtypes.NoneType.If
@no_type_checkhas been applied to obj, an empty dictionary is returned.If obj is a class
C, the function returns a dictionary that merges annotations fromC’s base classes with those onCdirectly. This is done by traversingC.__mro__and iteratively combining__annotations__dictionaries. Annotations on classes appearing earlier in the method resolution order always take precedence over annotations on classes appearing later in the method resolution order.The function recursively replaces all occurrences of
Annotated[T, ...]withT, unless include_extras is set toTrue(seeAnnotatedfor more information).
See also
inspect.get_annotations(), a lower-level function that returns annotations more directly.Nota
If any forward references in the annotations of obj are not resolvable or are not valid Python code, this function will raise an exception such as
NameError. For example, this can happen with imported type aliases that include forward references, or with names imported underif TYPE_CHECKING.Distinto en la versión 3.9: Se agregó el parámetro
include_extrascomo parte de PEP 593. Consulte la documentación enAnnotatedpara obtener más información.Distinto en la versión 3.11: Anteriormente, se agregaba
Optional[t]en las anotaciones de funciones o métodos si se establecía un valor por defecto igual aNone. Ahora la anotación es retornada sin cambios.
- typing.get_origin(tp)¶
Obtiene la versión sin suscripción de un tipo: para un objeto de tipado de la forma
X[Y, Z, ...]devuelveX.Si
Xes un alias de módulo de tipado para una clase incorporada ocollections, se normalizará a la clase original. SiXes una instancia deParamSpecArgsoParamSpecKwargs, devuelve laParamSpecsubyacente. DevuelveNonepara objetos no soportados.Por ejemplo:
assert get_origin(str) is None assert get_origin(Dict[str, int]) is dict assert get_origin(Union[int, str]) is Union assert get_origin(Annotated[str, "metadata"]) is Annotated P = ParamSpec('P') assert get_origin(P.args) is P assert get_origin(P.kwargs) is P
Added in version 3.8.
- typing.get_args(tp)¶
Obtiene los argumentos de tipo con todas las sustituciones realizadas: para un objeto de tipo con la forma
X[Y, Z, ...]devuelve(Y, Z, ...).Si
Xes una unión oLiteralcontenida en otro tipo genérico, el orden de(Y, Z, ...)puede ser diferente del orden de los argumentos originales[Y, Z, ...]debido al almacenamiento en caché de tipos. Devuelve()para objetos no soportados.Por ejemplo:
assert get_args(int) == () assert get_args(Dict[int, str]) == (int, str) assert get_args(Union[int, str]) == (int, str)
Added in version 3.8.
- typing.get_protocol_members(tp)¶
Return the set of members defined in a
Protocol.>>> from typing import Protocol, get_protocol_members >>> class P(Protocol): ... def a(self) -> str: ... ... b: int >>> get_protocol_members(P) == frozenset({'a', 'b'}) True
Raise
TypeErrorfor arguments that are not Protocols.Added in version 3.13.
- typing.is_protocol(tp)¶
Determine if a type is a
Protocol.Por ejemplo:
class P(Protocol): def a(self) -> str: ... b: int is_protocol(P) # => True is_protocol(int) # => False
Added in version 3.13.
- typing.is_typeddict(tp)¶
Compruebe si un tipo es
TypedDict.Por ejemplo:
class Film(TypedDict): title: str year: int assert is_typeddict(Film) assert not is_typeddict(list | str) # TypedDict is a factory for creating typed dicts, # not a typed dict itself assert not is_typeddict(TypedDict)
Added in version 3.10.
- class typing.ForwardRef¶
Clase utilizada para la representación interna de tipado de cadenas de caracteres en referencias futuras.
Por ejemplo,
List["SomeClass"]se transforma implícitamente enList[ForwardRef("SomeClass")].ForwardRefno debe ser instanciado por un usuario, pero puede ser utilizado por herramientas de introspección.Nota
Los tipos genéricos de PEP 585, como
list["SomeClass"], no se transformarán implícitamente enlist[ForwardRef("SomeClass")]y, por lo tanto, no se resolverán automáticamente enlist[SomeClass].Added in version 3.7.4.
- typing.NoDefault¶
A sentinel object used to indicate that a type parameter has no default value. For example:
>>> T = TypeVar("T") >>> T.__default__ is typing.NoDefault True >>> S = TypeVar("S", default=None) >>> S.__default__ is None True
Added in version 3.13.
Constantes¶
- typing.TYPE_CHECKING¶
Una constante especial que los validadores de tipos estáticos de terceros asumen como
True. EsFalseen 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_moden tiempo de ejecución. Las anotaciones de tipo para variables locales no se evalúan, así que la segunda anotación no necesita comillas.Nota
Si se utiliza
from __future__ import annotations, las anotaciones no son evaluadas al momento de la definición de funciones. En cambio, serán almacenadas como cadenas de texto en__annotations__. Ésto vuelve innecesario el uso de comillas alrededor de la anotación (véase PEP 563).Added in version 3.5.2.
Alias obsoletos¶
This module defines several deprecated aliases to pre-existing
standard library classes. These were originally included in the typing
module in order to support parameterizing these generic classes using [].
However, the aliases became redundant in Python 3.9 when the
corresponding pre-existing classes were enhanced to support [] (see
PEP 585).
Los tipos redundantes están obsoletos a partir de Python 3.9. Sin embargo, si bien los alias pueden eliminarse en algún momento, actualmente no se planea eliminarlos. Por lo tanto, el intérprete no emite advertencias de obsolescencia para estos alias.
If at some point it is decided to remove these deprecated aliases, a
deprecation warning will be issued by the interpreter for at least two releases
prior to removal. The aliases are guaranteed to remain in the typing module
without deprecation warnings until at least Python 3.14.
Se recomienda a los validadores de tipos que marquen los usos de los tipos obsoletos si el programa que están verificando apunta a una versión mínima de Python 3.9 o más reciente.
Alias de tipos integrados¶
- class typing.Dict(dict, MutableMapping[KT, VT])¶
Alias obsoleto de
dict.Note that to annotate arguments, it is preferred to use an abstract collection type such as
Mappingrather than to usedictortyping.Dict.Obsoleto desde la versión 3.9:
builtins.dictahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.List(list, MutableSequence[T])¶
Alias obsoleto de
list.Note that to annotate arguments, it is preferred to use an abstract collection type such as
SequenceorIterablerather than to uselistortyping.List.Obsoleto desde la versión 3.9:
builtins.listahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.Set(set, MutableSet[T])¶
Alias obsoleto de
builtins.set.Note that to annotate arguments, it is preferred to use an abstract collection type such as
collections.abc.Setrather than to usesetortyping.Set.Obsoleto desde la versión 3.9:
builtins.setahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.FrozenSet(frozenset, AbstractSet[T_co])¶
Alias obsoleto de
builtins.frozenset.Obsoleto desde la versión 3.9:
builtins.frozensetahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- typing.Tuple¶
Alias obsoleto de
tuple.tupleyTupleson casos especiales en el sistema de tipos; consulte Anotaciones en tuplas para más detalles.Obsoleto desde la versión 3.9:
builtins.tupleahora soporta el uso de subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.Type(Generic[CT_co])¶
Alias obsoleto de
type.Vea El tipo de objetos de clase para obtener detalles sobre el uso de
typeotyping.Typeen anotaciones de tipo.Added in version 3.5.2.
Obsoleto desde la versión 3.9:
builtins.typeahora soporta el uso de subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
Alias de tipos en collections¶
- class typing.DefaultDict(collections.defaultdict, MutableMapping[KT, VT])¶
Alias obsoleto de
collections.defaultdict.Added in version 3.5.2.
Obsoleto desde la versión 3.9:
collections.defaultdictahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.OrderedDict(collections.OrderedDict, MutableMapping[KT, VT])¶
Alias obsoleto de
collections.OrderedDict.Added in version 3.7.2.
Obsoleto desde la versión 3.9:
collections.OrderedDictahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.ChainMap(collections.ChainMap, MutableMapping[KT, VT])¶
Alias obsoleto de
collections.ChainMap.Added in version 3.6.1.
Obsoleto desde la versión 3.9:
collections.ChainMapahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.Counter(collections.Counter, Dict[T, int])¶
Alias obsoleto de
collections.Counter.Added in version 3.6.1.
Obsoleto desde la versión 3.9:
collections.Counterahora soporta subíndices ([])`. Véase PEP 585 y Tipo Alias Genérico.
- class typing.Deque(deque, MutableSequence[T])¶
Alias obsoleto de
collections.deque.Added in version 3.6.1.
Obsoleto desde la versión 3.9:
collections.dequeahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
Alias a otros tipos concretos¶
- class typing.Pattern¶
- class typing.Match¶
Alias obsoletos correspondientes a los tipos de retorno
re.compile()yre.match().Estos tipos (y las funciones correspondientes) son genéricos sobre
AnyStr.Patternse puede especializar comoPattern[str]oPattern[bytes];Matchse puede especializar comoMatch[str]oMatch[bytes].Obsoleto desde la versión 3.9: Las clases
PatternyMatchdereahora soportan[]. Véase PEP 585 y Tipo Alias Genérico.
- class typing.Text¶
Alias obsoleto para
str.Se indica
Textpara proporcionar compatibilidad con versiones de código posteriores a Python 2: en Python 2,Textes un alias paraunicode.Úsese
Textpara indicar que un valor debe contener una cadena de texto Unicode de manera que sea compatible con Python 2 y Python 3:def add_unicode_checkmark(text: Text) -> Text: return text + u' \u2713'
Added in version 3.5.2.
Obsoleto desde la versión 3.11: Python 2 ya no es compatible, y la mayoría de los validadores de tipos tampoco admiten la verificación de tipos de código Python 2. La eliminación del alias no está planeada actualmente, pero se recomienda a los usuarios utilizar
stren lugar deText.
Alias de ABCs de contenedores en collections.abc¶
- class typing.AbstractSet(Collection[T_co])¶
Alias obsoleto de
collections.abc.Set.Obsoleto desde la versión 3.9:
collections.abc.Setahora 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, ymemoryviewde secuencias de bytes.Deprecated since version 3.9, will be removed in version 3.14: Preferiblemente use
collections.abc.Buffer, o una unión comobytes | bytearray | memoryview.
- class typing.Collection(Sized, Iterable[T_co], Container[T_co])¶
Alias obsoleto de
collections.abc.Collection.Added in version 3.6.
Obsoleto desde la versión 3.9:
collections.abc.Collectionahora soporta la sintaxis de subíndice ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.Container(Generic[T_co])¶
Alias obsoleto de
collections.abc.Container.Obsoleto desde la versión 3.9:
collections.abc.Containerahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.ItemsView(MappingView, AbstractSet[tuple[KT_co, VT_co]])¶
Alias obsoleto de
collections.abc.ItemsView.Obsoleto desde la versión 3.9:
collections.abc.ItemsViewahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.KeysView(MappingView, AbstractSet[KT_co])¶
Alias obsoleto de
collections.abc.KeysView.Obsoleto desde la versión 3.9:
collections.abc.KeysViewahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.Mapping(Collection[KT], Generic[KT, VT_co])¶
Alias obsoleto de
collections.abc.Mapping.Obsoleto desde la versión 3.9:
collections.abc.Mappingahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.MappingView(Sized)¶
Alias obsoleto de
collections.abc.MappingView.Obsoleto desde la versión 3.9:
collections.abc.MappingViewahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.MutableMapping(Mapping[KT, VT])¶
Alias obsoleto de
collections.abc.MutableMapping.Obsoleto desde la versión 3.9:
collections.abc.MutableMappingahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.MutableSequence(Sequence[T])¶
Alias obsoleto de
collections.abc.MutableSequence.Obsoleto desde la versión 3.9:
collections.abc.MutableSequenceahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.MutableSet(AbstractSet[T])¶
Alias obsoleto de
collections.abc.MutableSet.Obsoleto desde la versión 3.9:
collections.abc.MutableSetahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.Sequence(Reversible[T_co], Collection[T_co])¶
Alias obsoleto de
collections.abc.Sequence.Obsoleto desde la versión 3.9:
collections.abc.Sequenceahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.ValuesView(MappingView, Collection[_VT_co])¶
Alias obsoleto de
collections.abc.ValuesView.Obsoleto desde la versión 3.9:
collections.abc.ValuesViewahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
Alias para ABCs asíncronos en collections.abc¶
- class typing.Coroutine(Awaitable[ReturnType], Generic[YieldType, SendType, ReturnType])¶
Alias obsoleto de
collections.abc.Coroutine.See Annotating generators and coroutines for details on using
collections.abc.Coroutineandtyping.Coroutinein type annotations.Added in version 3.5.3.
Obsoleto desde la versión 3.9:
collections.abc.Coroutineahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.AsyncGenerator(AsyncIterator[YieldType], Generic[YieldType, SendType])¶
Alias obsoleto de
collections.abc.AsyncGenerator.See Annotating generators and coroutines for details on using
collections.abc.AsyncGeneratorandtyping.AsyncGeneratorin type annotations.Added in version 3.6.1.
Obsoleto desde la versión 3.9:
collections.abc.AsycGeneratorahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.Distinto en la versión 3.13: The
SendTypeparameter now has a default.
- class typing.AsyncIterable(Generic[T_co])¶
Alias obsoleto de
collections.abc.AsyncIterable.Added in version 3.5.2.
Obsoleto desde la versión 3.9:
collections.abc.AsyncIterableahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.AsyncIterator(AsyncIterable[T_co])¶
Alias obsoleto de
collections.abc.AsyncIterator.Added in version 3.5.2.
Obsoleto desde la versión 3.9:
collections.abc.AsyncIteratorahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.Awaitable(Generic[T_co])¶
Alias obsoleto de
collections.abc.Awaitable.Added in version 3.5.2.
Obsoleto desde la versión 3.9:
collections.abc.Awaitableahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
Alias a otros ABCs en collections.abc¶
- class typing.Iterable(Generic[T_co])¶
Alias obsoleto de
collections.abc.Iterable.Obsoleto desde la versión 3.9:
collections.abc.Iterableahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.Iterator(Iterable[T_co])¶
Alias obsoleto de
collections.abc.Iterator.Obsoleto desde la versión 3.9:
collections.abc.Iteratorahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- typing.Callable¶
Alias obsoleto de
collections.abc.Callable.Vea Anotaciones en objetos invocables para información detallada de cómo usar
collections.abc.Callableytyping.Callableen anotaciones de tipo.Obsoleto desde la versión 3.9:
collections.abc.Callableahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.Distinto en la versión 3.10:
Callableahora es compatible conParamSpecyConcatenate. Consulte PEP 612 para obtener más información.
- class typing.Generator(Iterator[YieldType], Generic[YieldType, SendType, ReturnType])¶
Alias obsoleto de
collections.abc.Generator.See Annotating generators and coroutines for details on using
collections.abc.Generatorandtyping.Generatorin type annotations.Obsoleto desde la versión 3.9:
collections.abc.Generatorahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.Distinto en la versión 3.13: Default values for the send and return types were added.
- class typing.Hashable¶
Alias obsoleto de
collections.abc.Hashable.Obsoleto desde la versión 3.12: Use directamente
collections.abc.Hashableen su lugar.
- class typing.Reversible(Iterable[T_co])¶
Alias obsoleto de
collections.abc.Reversible.Obsoleto desde la versión 3.9:
collections.abc.Reversibleahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.
- class typing.Sized¶
Alias obsoleto de
collections.abc.Sized.Obsoleto desde la versión 3.12: Use directamente
collections.abc.Sizeden su lugar.
Alias de ABCs contextlib¶
- class typing.ContextManager(Generic[T_co, ExitT_co])¶
Alias obsoleto de
contextlib.AbstractContextManager.The first type parameter,
T_co, represents the type returned by the__enter__()method. The optional second type parameter,ExitT_co, which defaults tobool | None, represents the type returned by the__exit__()method.Added in version 3.5.4.
Obsoleto desde la versión 3.9:
contextlib.AbstractContextManagerahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.Distinto en la versión 3.13: Added the optional second type parameter,
ExitT_co.
- class typing.AsyncContextManager(Generic[T_co, AExitT_co])¶
Alias obsoleto de
contextlib.AbstractAsyncContextManager.The first type parameter,
T_co, represents the type returned by the__aenter__()method. The optional second type parameter,AExitT_co, which defaults tobool | None, represents the type returned by the__aexit__()method.Added in version 3.6.2.
Obsoleto desde la versión 3.9:
contextlib.AbstractAsyncContextManagerahora soporta subíndices ([]). Véase PEP 585 y Tipo Alias Genérico.Distinto en la versión 3.13: Added the optional second type parameter,
AExitT_co.
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 |
3.9 |
No decidido (ver Alias obsoletos para más información) |
|
3.9 |
3.14 |
||
3.11 |
No decidido |
||
3.12 |
No decidido |
||
3.12 |
No decidido |
||
3.13 |
3.15 |
||
3.13 |
3.18 |