typing
— Suporte para dicas de tipo¶
Adicionado na versão 3.5.
Código-fonte: Lib/typing.py
Nota
O tempo de execução do Python não força anotações de tipos de variáveis e funções. Elas podem ser usadas por ferramentas de terceiros como verificadores de tipo, IDEs, linters, etc.
Este módulo fornece suporte em tempo de execução para dicas de tipo.
Considere a função abaixo:
def surface_area_of_cube(edge_length: float) -> str:
return f"The surface area of the cube is {6 * edge_length ** 2}."
A função surface_area_of_cube
recebe um argumento que se espera ser uma instância de float
, conforme indicado pela dica de tipo edge_length: float
. Espera-se que a função retorne uma instância de str
, conforme indicado pela dica -> str
.
Embora as dicas de tipo possam ser classes simples como float
ou str
, elas também podem ser mais complexas. O módulo typing
fornece um vocabulário de dicas de tipo mais avançadas.
Novos recursos são frequentemente adicionados ao módulo typing
. O pacote typing_extensions fornece backports desses novos recursos para versões mais antigas do Python.
Ver também
- “Guia rápido sobre Dicas de Tipo”
Uma visão geral das dicas de tipo (hospedado por mypy docs, em inglês).
- “Referência sobre Sistema de Tipo” seção de the mypy docs
O sistema de tipagem do Python é padronizado pelas PEPs, portanto esta referência deve se aplicar a maioria do verificadores de tipo do Python. (Alguns trechos podem se referir especificamente ao mypy. Documento em inglês).
- “Tipagem Estática com Python”
Documentação independente de verificador de tipo escrita pela comunidade, detalhando os recursos do sistema de tipo, ferramentas úteis de tipagem e melhores práticas.
Especificação para o sistema de tipos do Python¶
A especificação canônica e atualizada do sistema de tipos Python pode ser encontrada em “Specification for the Python type system”.
Apelidos de tipo¶
Um apelido de tipo é definido utilizando a instrução type
, que por sua vez cria uma instância da classe TypeAliasType
. Neste exemplo, Vector
e list[float]
serão tratados de maneira equivalente pelos verificadores de tipo estático:
type Vector = list[float]
def scale(scalar: float, vector: Vector) -> Vector:
return [scalar * num for num in vector]
# passa na verificação de tipos; uma lista de floats é qualificada como Vector.
new_vector = scale(2.0, [1.0, -4.2, 5.4])
Apelidos de tipo são úteis para simplificar assinaturas de tipo complexas. Por exemplo:
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:
...
# O verificador de tipo tratará a assinatura de tipo anterior
# como exatamente equivalente à assinatura abaixo.
def broadcast_message(
message: str,
servers: Sequence[tuple[tuple[str, int], dict[str, str]]]
) -> None:
...
A instrução type
é nova no Python 3.12. Para compatibilidade retroativa, apelidos de tipo também podem ser criados através da simples atribuição:
Vector = list[float]
Ou marcado com TypeAlias
para tornar explícito que se trata de um apelido de tipo e não uma atribuição de variável comum:
from typing import TypeAlias
Vector: TypeAlias = list[float]
NewType¶
Utilize o auxiliar NewType
para criar tipos únicos:
from typing import NewType
UserId = NewType('UserId', int)
some_id = UserId(524313)
O verificador de tipo estático tratará o novo tipo como se fosse uma subclasse do tipo original. Isso é útil para ajudar a encontrar erros de lógica:
def get_user_name(user_id: UserId) -> str:
...
# passa na verificação de tipo
user_a = get_user_name(UserId(42351))
# falha na verificação de tipo: um int não é um UserId
user_b = get_user_name(-1)
Você ainda pode executar todas as operações int
em uma variável do tipo UserId
, mas o resultado sempre será do tipo int
. Isso permite que você passe um UserId
em qualquer ocasião que int
possa ser esperado, mas previne que você acidentalmente crie um UserId
de uma forma inválida:
# 'output' é do tipo 'int', em vez de 'UserId'
output = UserId(23413) + UserId(54341)
Note que essas verificações são aplicadas apenas pelo verificador de tipo estático. Em tempo de execução, a instrução Derived = NewType('Derived', Base)
irá tornar Derived
um chamável que retornará imediatamente qualquer parâmetro que você passar. Isso significa que a expressão Derived(some_value)
não cria uma nova classe ou introduz sobrecarga além de uma chamada regular de função.instrução
Mais precisamente, a expressão some_value is Derived(some_value)
é sempre verdadeira em tempo de execução.
É inválido criar um subtipo de Derived
:
from typing import NewType
UserId = NewType('UserId', int)
# Falha em tempo de execução e não passa na verificação de tipos
class AdminUserId(UserId): pass
No entanto, é possível criar um NewType
baseado em um ‘derivado’ NewType
:
from typing import NewType
UserId = NewType('UserId', int)
ProUserId = NewType('ProUserId', UserId)
e a verificação de tipos para ProUserId
funcionará como esperado.
Veja PEP 484 para mais detalhes.
Nota
Lembre-se que o uso de um apelido de tipo declara que dois tipos serão equivalentes entre si. Efetuar type Alias = Original
fará o verificador de tipo estático tratar Alias
como sendo exatamente equivalente a Original
em todos os casos. Isso é útil quando você deseja simplificar assinaturas de tipo complexas.
Em contraste, NewType
declara que um tipo será subtipo de outro. Efetuando Derived = NewType('Derived', Original)
irá fazer o verificador de tipo estático tratar Derived
como uma subclasse de Original
, o que significa que um valor do tipo Original
não pode ser utilizado onde um valor do tipo Derived
é esperado. Isso é útil quando você deseja evitar erros de lógica com custo mínimo de tempo de execução.
Adicionado na versão 3.5.2.
Alterado na versão 3.10: NewType
agora é uma classe em vez de uma função. Consequentemente, existem alguns custos em tempo de execução ao chamar NewType
em vez de uma função comum.
Alterado na versão 3.11: O desempenho de chamar NewType
voltou ao mesmo nível da versão Python 3.9.
Anotações de objetos chamáveis¶
Funções – ou outros objetos chamáveis – podem ser anotados com collections.abc.Callable
ou com o typing.Callable
descontinuado. Callable[[int], str]
expressa uma função que recebe um único parâmetro de tipo int
e retorna uma str
.
Por exemplo:
from collections.abc import Callable, Awaitable
def feeder(get_next_item: Callable[[], str]) -> None:
... # Corpo
def async_query(on_success: Callable[[int], None],
on_error: Callable[[int, Exception], None]) -> None:
... # Corpo
async def on_update(value: str) -> None:
... # Corpo
callback: Callable[[str], Awaitable[None]] = on_update
A sintaxe da subscrição deve sempre ser usada com exatamente dois valores: uma lista de argumentos e o tipo de retorno. A lista de argumentos deve ser uma lista de tipos, um ParamSpec
, Concatenate
, ou reticências. O tipo de retorno deve ser um único tipo.
Se uma reticências literal ...
é passada no lugar de uma lista de argumentos, ela indica que um chamável com uma lista de qualquer parâmetro arbitrário seria aceita.
def concat(x: str, y: str) -> str:
return x + y
x: Callable[..., str]
x = str # OK
x = concat # OK também
Callable
não pode representar assinaturas complexas, como funções que aceitam um número variado de argumentos, funções sobrecarregadas, or funções que recebem apenas parâmetros somente-nomeados. No entanto, essas assinaturas podem ser expressas ao se definir uma Protocol
com um método __call__()
:
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) # Erro! Argumento 2 tem tipo incompatível por ter
# nome e tipo diferente do callback
Chamáveis que recebem outros chamáveis como argumentos podem indicar que seus tipos de parâmetro dependem uns dos outros usando ParamSpec
. Além disso, se esse chamável adiciona ou remove argumentos de outros chamáveis, o operador Concatenate
pode ser usado. Eles assumem a forma de Callable[ParamSpecVariable, ReturnType]
e Callable[Concatenate[Arg1Type, Arg2Type, ..., ParamSpecVariable], ReturnType]
, respectivamente.
Alterado na versão 3.10: Callable
agora oferece suporte a ParamSpec
e Concatenate
. Veja PEP 612 para mais detalhes.
Ver também
A documentação para ParamSpec
e Concatenate
contém exemplos de uso em Callable
.
Genéricos¶
Como a informação de tipo sobre objetos mantidos em contêineres não pode ser inferida estaticamente de uma maneira genérica, muitas classes de contêiner na biblioteca padrão permitem subscrição para denotar tipos esperados de elementos de contêiner.
from collections.abc import Mapping, Sequence
class Employee: ...
# Sequence[Employee] indica que todos os elementos na sequência
# devem ser instâncias de "Employee".
# Mapping[str, str] indica que todas as chaves e valores no mapeamento
# devem ser strings.
def notify_by_email(employees: Sequence[Employee],
overrides: Mapping[str, str]) -> None: ...
Funções e classes genéricas podem ser parametrizadas utilizando a sintaxe de parâmetro de tipos:
from collections.abc import Sequence
def first[T](l: Sequence[T]) -> T: # Função é genérica sobre TypeVar "T"
return l[0]
Ou utilizando a fábrica TypeVar
diretamente:
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]
Alterado na versão 3.12: O suporte sintático para genéricos é novo no Python 3.12.
Anotando tuplas¶
Para a maior parte dos tipos containers em Python, o sistema de tipagem presume que todos os elementos do contêiner são do mesmo tipo. Por exemplo:
from collections.abc import Mapping
# Verificador de tipos irá inferor que todos os elementos em ``x`` devem ser ints
x: list[int] = []
# Erro no verificador: ``list`` aceita um único tipo de argumento
y: list[int, str] = [1, 'foo']
# Verificador de tipos irá inferir que todas as chaves em ``z`` devem ser strings,
# e todos os valores em ``z`` devem ser strings ou ints
z: Mapping[str, str | int] = {}
list
aceita apenas um tipo de argumento, e assim o verificador de tipos emitirá um erro na atribuição y
acima. Da mesma forma, Mapping
aceita apenas dois tipos de argumento: O primeiro indica o tipo das chaves, e o segundo indica o tipo dos valores.
Ao contrário da maioria dos outros contêineres Python, é comum no código Python idiomático que as tuplas tenham elementos que não sejam todos do mesmo tipo. Por esse motivo, as tuplas têm um caso especial no sistema de tipagem do Python. tuple
aceita qualquer quantidade de argumentos de tipo:
# OK: ``x`` foi atribuída a uma tupla de comprimento 1, onde o único elemento é um int
x: tuple[int] = (5,)
# OK: ``y`` foi atribuída a uma tupla de comprimento 2;
# o elemento 1 é um int, o elemento 2 é uma str
y: tuple[int, str] = (5, "foo")
# Erro: a anotação de tipo indica uma tupla de comprimento 1,
# mas ``z`` foi atribuída a uma tupla de comprimento 3
z: tuple[int] = (1, 2, 3)
Para indicar um tupla que pode ser de qualquer comprimento, e no qual todos os elementos são do mesmo tipo T
, use tuple[T, ...]
. Para denotar um tupla vazia, use tuple[()]
. Usando apenas tuple
como anotação, é equivalente a usar tuple[Any, ...]
:
x: tuple[int, ...] = (1, 2)
# Essas reatribuições são OK: ``tuple[int, ...]`` indica que x pode ter qualquer comprimento
x = (1, 2, 3)
x = ()
# Essa reatribuição é um erro: todos os elementos de ``x`` devem ser ints
x = ("foo", "bar")
# ``y`` só pode ser atribuída a uma tupla vazia
y: tuple[()] = ()
z: tuple = ("foo", "bar")
# Essas reatribuições são OK: o tipo ``tuple`` equivale a ``tuple[Any, ...]``
z = (1, 2, 3)
z = ()
O tipo de objetos de classe¶
Uma variável anotada com C
pode aceitar um valor de tipo C
. Por outro lado, uma variável anotada com type[C]
(ou o tipo descontinuado typing.Type[C]
) pode aceitar valores que são as próprias classes – mais especificamente, ela aceitará o objeto classe de C
. Por exemplo:
a = 3 # Tem tipo ``int``
b = int # Tem tipo ``type[int]``
c = type(a) # Também tem tipo ``type[int]``
Observe que type[C]
é 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) # Também OK: ``type[ProUser]`` é subtipo de ``type[User]``
make_new_user(TeamUser) # Tudo bem
make_new_user(User()) # Erro: esperava-se ``type[User]`` mas retornou ``User``
make_new_user(int) # Erro: ``type[int]`` não é subtipo de ``type[User]``
Os únicos parâmetros válidos para type
são classes, Any
, type variables e uniões de qualquer um desses tipos. Por exemplo:
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) # Erro: ``type[TeamUser]`` não é subtipo
# de ``type[BasicUser | ProUser]``
new_non_team_user(User) # Também é um erro
type[Any]
é equivalente a type
, que é a raiz da hierarquia de metaclasses do Python.
Anotando geradores e corrotinas¶
Um gerador pode ser anotado usando um tipo genérico Generator[YieldType, SendType, ReturnType]
. Por exemplo:
def echo_round() -> Generator[int, float, str]:
sent = yield 0
while sent >= 0:
sent = yield round(sent)
return 'Done'
Note que, diferentemente de outras classes genéricas na biblioteca padrão, o ``SendType``da classe Generator
se comporta contravariantemente, em vez de covariantemente ou invariantemente.
Os parâmetros SendType
e ReturnType
são None
por padrão:
def infinite_stream(start: int) -> Generator[int]:
while True:
yield start
start += 1
Também é possível definir esses tipos explicitamente:
def infinite_stream(start: int) -> Generator[int, None, None]:
while True:
yield start
start += 1
Geradores simples que só produzem valores também podem ser anotados com tipo de retorno Iterable[YieldType]
ou Iterator[YieldType]
:
def infinite_stream(start: int) -> Iterator[int]:
while True:
yield start
start += 1
Geradores assíncronos são manipulados similarmente, mas não espere um argumento de tipo ReturnType
(AsyncGenerator[YieldType, SendType]
). O argumento SendType
é None
por padrão, então as seguintes definições são equivalentes:
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)
Como no caso síncrono, AsyncIterable[YieldType]
e AsyncIterator[YieldType]
também estão disponíveis:
async def infinite_stream(start: int) -> AsyncIterator[int]:
while True:
yield start
start = await increment(start)
Corrotinas podem ser anotadas usando Coroutine[YieldType, SendType, ReturnType]
. Argumentos genéricos correspondem àqueles da classe Generator
, por exemplo:
from collections.abc import Coroutine
c: Coroutine[list[str], str, int] # Uma corrotina defina em outro lugar
x = c.send('hi') # Tipo inferido de 'x' é list[str]
async def bar() -> None:
y = await c # Tipo inferido de 'y' é int
Tipos genéricos definidos pelo usuário¶
Uma classe definida pelo usuário pode ser definica como uma classe genérica.
from logging import Logger
class LoggedVar[T]:
def __init__(self, value: T, name: str, logger: Logger) -> None:
self.name = name
self.logger = logger
self.value = value
def set(self, new: T) -> None:
self.log('Set ' + repr(self.value))
self.value = new
def get(self) -> T:
self.log('Get ' + repr(self.value))
return self.value
def log(self, message: str) -> None:
self.logger.info('%s: %s', self.name, message)
Esta sintaxe indica que o classe LoggedVar
é parametrizada em torno de uma única type variable T
. Isso também torna T
válido como um tipo dentro do corpo da classe.
Classes genéricas implicitamente herdar de Generic
. Para compatibilidade com Python 3.11 e versões inferiores, também é possível herdar explicitamente de Generic
para indicar uma classe genérica:
from typing import TypeVar, Generic
T = TypeVar('T')
class LoggedVar(Generic[T]):
...
Classes genéricas têm métodos __class_getitem__()
, o que significa que podem ser parametrizadas em tempo de execução (por exemplo, LoggedVar[int]
abaixo):
from collections.abc import Iterable
def zero_all_vars(vars: Iterable[LoggedVar[int]]) -> None:
for var in vars:
var.set(0)
Um tipo genérico pode ter qualquer número de tipos de variáveis. Todas as variedades de TypeVar
são permitidas como parâmetros para um 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 tipo dos argumentos para Generic
devem ser distintos. Assim, os seguintes exemplos são inválidos:
from typing import TypeVar, Generic
...
class Pair[M, M]: # SyntaxError
...
T = TypeVar('T')
class Pair(Generic[T, T]): # INVÁLIDO
...
Classes genéricas podem também herdar de outras classes:
from collections.abc import Sized
class LinkedList[T](Sized):
...
Ao herdar das classes genérico, algun tipos podem ser fixos:
from collections.abc import Mapping
class MyDict[T](Mapping[str, T]):
...
Neste caso MyDict
possui um único parâmetro, T
.
O uso de uma classe genérica sem especificar tipos pressupõe Any
para cada posição. No exemplo a seguir, MyIterable
não é genérico, mas herda implicitamente de Iterable[Any]
:
from collections.abc import Iterable
class MyIterable(Iterable): # Igual a Iterable[Any]
...
Também há suporte para tipos genéricos definidos pelo usuário. Exemplos:
from collections.abc import Iterable
type Response[S] = Iterable[S] | int
# Tipo de retorno aqui é igual a 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: # Igual a Iterable[tuple[T, T]]
return sum(x*y for x, y in v)
Para compatibilidade retroativa, os apelidos para tipos genéricos também podem ser criados por meio de um simples atribuição:
from collections.abc import Iterable
from typing import TypeVar
S = TypeVar("S")
Response = Iterable[S] | int
Alterado na versão 3.7: Generic
não possui mais uma metaclasse personalizada.
Alterado na versão 3.12: Suporte sintático para apelidos de tipo e genéricos é novo na versão 3.12. Anteriormente, as classes genéricas precisavam explicitamente herdar de Generic
ou conter um tipo de variável em uma de suas bases.
Genéricos definidos pelo usuário para expressões de parâmetros também oferecem suporte por meio de variáveis de especificação de parâmetros no formato [**P]
. O comportamento é consistente com as variáveis de tipo descritas acima, pois as variáveis de especificação de parâmetro são tratadas pelo módulo typing como uma variável de tipo especializada. A única exceção a isso é que uma lista de tipos pode ser usada para substituir um ParamSpec
:
>>> class Z[T, **P]: ... # T é um TypeVar; P é um ParamSpec
...
>>> Z[int, [dict, float]]
__main__.Z[int, [dict, float]]
Classes genéricas sobre um ParamSpec
também podem ser criadas usando herança explícita de Generic
. Neste caso, **
não é usado:
from typing import ParamSpec, Generic
P = ParamSpec('P')
class Z(Generic[P]):
...
Outra diferença entre TypeVar
e ParamSpec
é que um genérico com apenas uma variável de especificação de parâmetro aceitará listas de parâmetros nos formatos X[[Type1, Type2, ...]]
e também X[Type1, Type2, ...]
por razões estéticas. Internamente, o último é convertido no primeiro, portanto são equivalentes:
>>> class X[**P]: ...
...
>>> X[int, str]
__main__.X[[int, str]]
>>> X[[int, str]]
__main__.X[[int, str]]
Observe que genéricos com ParamSpec
podem não ter __parameters__
corretos após a substituição em alguns casos porque eles são destinados principalmente à verificação de tipo estático.
Alterado na versão 3.10: Generic
agora pode ser parametrizado através de expressões de parâmetros. Veja ParamSpec
e PEP 612 para mais detalhes.
Uma classe genérica definida pelo usuário pode ter ABCs como classes base sem conflito de metaclasse. Não há suporte a metaclasses genéricas. O resultado da parametrização de genéricos é armazenado em cache, e a maioria dos tipos no módulo typing são hasheáveis e comparáveis em termos de igualdade.
O tipo Any
¶
Um tipo especial de tipo é Any
. Um verificador de tipo estático tratará cada tipo como sendo compatível com Any
e Any
como sendo compatível com todos os tipos.
Isso significa que é possível realizar qualquer operação ou chamada de método sobre um valor do tipo Any
e atribuí-lo a qualquer variável:
from typing import Any
a: Any = None
a = [] # OK
a = 2 # OK
s: str = ''
s = a # OK
def foo(item: Any) -> int:
# Passa na verificação de tipos; 'item' pode ser qualquer tipo,
# e esse tipo pode ter um método 'bar'
item.bar()
...
Observe que nenhuma verificação de tipo é realizada ao atribuir um valor do tipo Any
a um tipo mais preciso. Por exemplo, o verificador de tipo estático não relatou um erro ao atribuir a
a s
mesmo que s
tenha sido declarado como sendo do tipo str
e receba um valor int
em tempo de execução!
Além disso, todas as funções sem um tipo de retorno ou tipos de parâmetro terão como padrão implicitamente o uso de Any
:
def legacy_parser(text):
...
return data
# Um verificador de tipo estático tratará a função acima
# como tendo a mesma assinatura da função abaixo:
def legacy_parser(text: Any) -> Any:
...
return data
Este comportamento permite que Any
seja usado como uma saída de emergência quando você precisar misturar código tipado dinamicamente e estaticamente.
Compare o comportamento de Any
com o comportamento de object
. Semelhante a Any
, todo tipo é um subtipo de object
. No entanto, ao contrário de Any
, o inverso não é verdadeiro: object
não é um subtipo de qualquer outro tipo.
Isso significa que quando o tipo de um valor é object
, um verificador de tipo rejeitará quase todas as operações nele, e atribuí-lo a uma variável (ou usá-la como valor de retorno) de um tipo mais especializado é um tipo erro. Por exemplo:
def hash_a(item: object) -> int:
# Falha na verificação de tipo; um 'object' não tem um método 'magic'.
item.magic()
...
def hash_b(item: Any) -> int:
# Passa na verificação de tipo
item.magic()
...
# Passa na verificação de tipo, já que ints e strs são subclasses de 'object'
hash_a(42)
hash_a("foo")
# Passa na verificação de tipo, já que Any é compatível com todos os tipos
hash_b(42)
hash_b("foo")
Use object
para indicar que um valor pode ser de qualquer tipo de maneira segura. Use Any
para indicar que um valor é tipado dinamicamente.
Subtipagem nominal vs estrutural¶
Inicialmente a PEP 484 definiu o sistema de tipos estáticos do Python como usando subtipagem nominal. Isto significa que uma classe A
é permitida onde uma classe B
é esperada se e somente se A
for uma subclasse de B
.
Este requisito anteriormente também se aplicava a classes base abstratas, como Iterable
. O problema com essa abordagem é que uma classe teve que ser marcada explicitamente para suportá-los, o que não é pythônico e diferente do que normalmente seria feito em código Python de tipo dinamicamente idiomático. Por exemplo, isso está em conformidade com PEP 484:
from collections.abc import Sized, Iterable, Iterator
class Bucket(Sized, Iterable[int]):
...
def __len__(self) -> int: ...
def __iter__(self) -> Iterator[int]: ...
PEP 544 permite resolver este problema permitindo que os usuários escrevam o código acima sem classes base explícitas na definição de classe, permitindo que Bucket
seja implicitamente considerado um subtipo de Sized
e Iterable[int]
por verificador de tipo estático. Isso é conhecido como subtipagem estrutural (ou tipagem pato estática):
from collections.abc import Iterator, Iterable
class Bucket: # Nota: sem classes base
...
def __len__(self) -> int: ...
def __iter__(self) -> Iterator[int]: ...
def collect(items: Iterable[int]) -> int: ...
result = collect(Bucket()) # Passa na verificação de tipo
Além disso, ao criar uma subclasse de uma classe especial Protocol
, um usuário pode definir novos protocolos personalizados para aproveitar ao máximo a subtipagem estrutural (veja exemplos abaixo).
Conteúdo do módulo¶
O módulo typing
define as seguintes classes, funções e decoracores.
Tipos primitivos especiais¶
Tipos especiais¶
Eles podem ser usados como tipos em anotações. Eles não oferecem suporte a subscrição usando []
.
- typing.Any¶
Tipo especial que indica um tipo irrestrito.
Alterado na versão 3.11:
Any
agora pode ser usado como classe base. Isso pode ser útil para evitar erros do verificador de tipo com classes que podem digitar em qualquer lugar ou são altamente dinâmicas.
- typing.AnyStr¶
Uma variável de tipo restrito.
Definição:
AnyStr = TypeVar('AnyStr', str, bytes)
AnyStr
deve ser usado para funções que podem aceitar argumentosstr
oubytes
mas não podem permitir que os dois se misturem.Por exemplo:
def concat(a: AnyStr, b: AnyStr) -> AnyStr: return a + b concat("foo", "bar") # OK: saída tem tipo 'str' concat(b"foo", b"bar") # OK: saída tem tipo 'bytes' concat("foo", b"bar") # Erro: não se mistura str com bytes
Note que, apesar do nome,
AnyStr
não tem nada a ver com o tipoAny
, nem significa “qualquer string”. Em particular,AnyStr
estr | bytes
são diferentes entre si e têm casos de uso diferentes:# Uso inválido de AnyStr: # A variável de tipo é usada somente uma vez na assinatura da função, # então não pode ser "resolvida" pelo verificador de tipo def greet_bad(cond: bool) -> AnyStr: return "hi there!" if cond else b"greetings!" # O jeito melhor de anotar esta função 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: Descontinuado em favor da nova sintaxe de parâmetro de tipo. Use
class A[T: (str, bytes)]: ...
em vez de importarAnyStr
. Veja a PEP 695 para mais detalhes.No Python 3.16,
AnyStr
será removido detyping.__all__
, e avisos de descontinuação serão emitidos em tempo de execução quando ele for acessado ou importado detyping
.AnyStr
será removido dotyping
no Python 3.18.
- typing.LiteralString¶
Tipo especial que inclui apenas strings literais.
Qualquer literal de string é compatível com
LiteralString
, assim como outroLiteralString
. Entretanto, um objeto digitado apenasstr
não é. Uma string criada pela composição de objetos do tipoLiteralString
também é aceitável como umaLiteralString
.Exemplo:
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) # erro no verificador run_query( # erro no verificador f"SELECT * FROM students WHERE name = {arbitrary_string}" )
LiteralString
é útil para APIs sensíveis onde strings arbitrárias geradas pelo usuário podem gerar problemas. Por exemplo, os dois casos acima que geram erros no verificador de tipo podem ser vulneráveis a um ataque de injeção de SQL.Veja PEP 675 para mais detalhes.
Adicionado na versão 3.11.
- typing.Never¶
- typing.NoReturn¶
Never
eNoReturn
representam o tipo inferior, um tipo que não possui membros.Eles podem ser usados para indicar que uma função nunca retorna, como
sys.exit()
:from typing import Never # ou NoReturn def stop() -> Never: raise RuntimeError('no way')
Ou para definir uma função que nunca deve ser chamada, pois não existem argumentos válidos, como
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) # erro no verificador match arg: case int(): print("It's an int") case str(): print("It's a str") case _: never_call_me(arg) # OK, arg é do tipo Never (ou NoReturn)
Never
eNoReturn
têm o mesmo significado no sistema de tipos e os verificadores de tipo estático tratam ambos de forma equivalente.Adicionado na versão 3.6.2: Adicionado
NoReturn
.Adicionado na versão 3.11: Adicionado
Never
.
- typing.Self¶
Tipo especial para representar a classe atual inclusa.
Por exemplo:
from typing import Self, reveal_type class Foo: def return_self(self) -> Self: ... return self class SubclassOfFoo(Foo): pass reveal_type(Foo().return_self()) # Tipo revelado é "Foo" reveal_type(SubclassOfFoo().return_self()) # Tipo revelado é "SubclassOfFoo"
Esta anotação é semanticamente equivalente à seguinte, embora de forma mais sucinta:
from typing import TypeVar Self = TypeVar("Self", bound="Foo") class Foo: def return_self(self: Self) -> Self: ... return self
Em geral, se algo retorna
self
, como nos exemplos acima, você deve usarSelf
como anotação de retorno. SeFoo.return_self
foi anotado como retornando"Foo"
, então o verificador de tipo inferiria o objeto retornado deSubclassOfFoo.return_self
como sendo do tipoFoo
em vez deSubclassOfFoo
.Outros casos de uso comuns incluem:
classmethod
s que são usados como construtores alternativos e retornam instâncias do parâmetrocls
.Anotando um método
__enter__()
que retorna self.
Você não deveria usar
Self
como a anotação de retorno se não for garantido que o método retorne uma instância de uma subclasse quando a classe for subclassificada:class Eggs: # Self seria uma anotação de retorno incorreta aqui, # já que o objeto retornado sempre é instância de Eggs, # inclusive em subclasses def returns_eggs(self) -> "Eggs": return Eggs()
Veja PEP 673 para mais detalhes.
Adicionado na versão 3.11.
- typing.TypeAlias¶
Anotações especiais para declarar explicitamente um apelido de tipo.
Por exemplo:
from typing import TypeAlias Factors: TypeAlias = list[int]
TypeAlias
é particularmente útil em versões mais antigas do Python para anotar apelidos que fazem uso de referências futuras, pois pode ser difícil para os verificadores de tipo distingui-los das atribuições normais de variáveis:from typing import Generic, TypeAlias, TypeVar T = TypeVar("T") # "Box" não existe ainda, # então temos que usar aspas para a referência ao futuro em Python <3.12. # Usar ``TypeAlias`` diz ao verificador de tipo que isso é uma declaração de apelido de tipo, # e não uma atribuição de variável a string. BoxOfStrings: TypeAlias = "Box[str]" class Box(Generic[T]): @classmethod def make_box_of_strings(cls) -> BoxOfStrings: ...
Veja PEP 613 para mais detalhes.
Adicionado na versão 3.10.
Obsoleto desde a versão 3.12:
TypeAlias
foi descontinuado em favor da instruçãotype
, que cria instâncias deTypeAliasType
e que oferece suporte a nativamente referências futuras. Observe que emboraTypeAlias
eTypeAliasType
sirvam propósitos semelhantes e tenham nomes semelhantes, eles são distintos e o último não é o tipo do primeiro. A remoção deTypeAlias
não está planejada atualmente, mas os usuários são encorajados a migrar para instruçõestype
.
Formas especiais¶
Eles podem ser usados como tipos em anotações. Todos eles oferecem suporte a subscrição usando []
, mas cada um tem uma sintaxe única.
- typing.Union¶
Tipo de união;
Union[X, Y]
é equivalente aX | Y
e significa X ou Y.Para definir uma união, use, por exemplo.
Union[int, str]
ou a abreviaturaint | str
. Usar essa abreviação é recomendado. Detalhes:Os argumentos devem ser tipos e deve haver pelo menos um.
As uniões de uniões são achatadas, por exemplo:
Union[Union[int, str], float] == Union[int, str, float]
As uniões de um único argumento desaparecem, por exemplo:
Union[int] == int # O construtor retorna um int
Argumento redundantes são pulados, e.g.:
Union[int, str, int] == Union[int, str] == int | str
Ao comparar uniões, a ordem de argumentos é ignorada. Por exemplo:
Union[int, str] == Union[str, int]
Você não pode estender ou instanciar uma
Union
Você não pode escrever
Union[X][Y]
.
Alterado na versão 3.7: Não remova subclasses explícitas de uniões em tempo de execução.
Alterado na versão 3.10: Uniões agora podem ser escritas com
X | Y
. Veja expressões de união de tipos.
- typing.Optional¶
Optional[X]
equivale aX | None
(ouUnion[X, None]
).Note que isso não é o mesmo conceito de um argumento opcional, que possui um valor por padrão. Um argumento opcional com padrão não requer o qualificador
Optional
em sua anotação de tipo só por ser opcional. Por exemplo:def foo(arg: int = 0) -> None: ...
Por outro lado, se um valor explícito de
None
for permitido, o uso deOptional
é apropriado, seja o argumento opcional ou não. Por exemplo:def foo(arg: Optional[int] = None) -> None: ...
Alterado na versão 3.10: Optional agora pode ser escrito como
X | None
. Veja expressões de união de tipos.
- typing.Concatenate¶
Forma especial para anotar funções de ordem superior.
Concatenate
pode ser usado em conjunção com Callable eParamSpec
para anotar um chamável de maior ordem que adiciona, remove ou transforma parâmetros de outro chamável. Seu uso é feito na formaConcatenate[Arg1Type, Arg2Type, ..., ParamSpecVariable]
,Concatenate
atualmente só é válido quando usado como primeiro argumento de um Callable. O último parâmetro deConcatenate
deve ser umParamSpec
ou reticências (...
).Por exemplo, para anotar um decorador
with_lock
que oferece uma instância dethreading.Lock
para a função decorada,Concatenate
pode ser usado para indicar quewith_lock
espera um chamável cujo primeiro argumento tem tipoLock
, e retorna um chamável com uma assinatura de tipos diferente. Neste caso, oParamSpec
indica que os tipos dos parâmetros do chamável retornado dependem dos tipos dos parâmetros do chamável de entrada:from collections.abc import Callable from threading import Lock from typing import Concatenate # Use esta trava para se certificar de que # uma única thread a executa a qualquer momento. my_lock = Lock() def with_lock[**P, R](f: Callable[Concatenate[Lock, P], R]) -> Callable[P, R]: '''Um decorador com segurança de tipos que oferece uma trava.''' def inner(*args: P.args, **kwargs: P.kwargs) -> R: # Oferece a trava como primeiro argumento. return f(my_lock, *args, **kwargs) return inner @with_lock def sum_threadsafe(lock: Lock, numbers: list[float]) -> float: '''Somatório de uma lista de números de modo seguro para threads.''' 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])
Adicionado na versão 3.10.
Ver também
PEP 612 – Variáveis de especificação de parâmetro (a PEP que introduz
ParamSpec
eConcatenate
)
- typing.Literal¶
Forma especial de tipagem para definir “tipos literais”.
Literal
pode ser usado para indicar aos verificadores de tipo que o objeto anotado tem valor equivalente a algum dos literais oferecidos.Por exemplo:
def validate_simple(data: Any) -> Literal[True]: # sempre retorna True ... type Mode = Literal['r', 'rb', 'w', 'wb'] def open_helper(file: str, mode: Mode) -> str: ... open_helper('/some/path', 'r') # Passa verificação de tipos open_helper('/other/path', 'typo') # Erro em verificação de tipos
Literal[...]
não é subclasse. Em tempo de execução, permite-se um valor arbitrário como argumento de tipo paraLiteral[...]
, mas verificadores de tipo podem impor restrições. Veja PEP 586 para mais detalhes sobre tipos literais.Adicionado na versão 3.8.
- typing.ClassVar¶
Uma construção especial de tipagem para marcar variáveis de classe.
Como introduzido na PEP 526, uma variável cuja anotação de tipo tem um invólucro ClassVar indica que um dado atributo deve ser usado como uma variável de classe, e que ele não deve ser definido em instâncias dessa classe. Modo de usar:
class Starship: stats: ClassVar[dict[str, int]] = {} # variável de classe damage: int = 10 # variável de instância
ClassVar
aceita apenas tipos e não pode ser subscrita posteriormente.ClassVar
não é uma classe, e não deve ser usada comisinstance()
ouissubclass()
.ClassVar
não muda com o comportamento do Python em tempo de execução, mas pode ser usada por verificadores de tipos de terceiros. Por exemplo, um verificador de tipos pode sinalizar que o seguinte código é errado:enterprise_d = Starship(3000) enterprise_d.stats = {} # Erro: atribuindo valor a variável de classe de uma instância Starship.stats = {} # Isso é OK
Adicionado na versão 3.5.3.
- typing.Final¶
Uma construção especial de tipagem para indicar nomes finais a verificadores de tipos
Nomes finais não podem ser reatribuídos em qualquer escopo. Nomes finais declarados em escopos de classe não podem ser substituídos em subclasses.
Por exemplo:
MAX_SIZE: Final = 9000 MAX_SIZE += 1 # Erro reportado pelo verificador de tipos class Connection: TIMEOUT: Final[int] = 10 class FastConnector(Connection): TIMEOUT = 1 # Error reportado pelo verificador de tipos
Não há verificação em tempo de execução dessas propriedades. Veja PEP 591 para mais detalhes.
Adicionado na versão 3.8.
- typing.Required¶
Uma construção especial de tipagem para marcar uma chave de
TypedDict
como necessária.Isso é útil principalmente para TypedDicts com
total=False
. VejaTypedDict
e PEP 655 para obter mais detalhes.Adicionado na versão 3.11.
- typing.NotRequired¶
Uma construção especial de tipagem para marcar uma chave de
TypedDict
como potencialmente ausente.Veja
TypedDict
e PEP 655 para obter mais detalhes.Adicionado na versão 3.11.
- typing.ReadOnly¶
Uma construção especial de tipagem para marcar um item de um
TypedDict
como somente leitura.Por exemplo:
class Movie(TypedDict): title: ReadOnly[str] year: int def mutate_movie(m: Movie) -> None: m["year"] = 1999 # permitido m["title"] = "The Matrix" # erro no verificador de tipos
Não há verificação em tempo de execução para esta propriedade.
Consulte
TypedDict
e PEP 705 para obter mais detalhes.Adicionado na versão 3.13.
- typing.Annotated¶
Forma especial de tipagem para adicionar metadados específicos de contexto para uma anotação.
Adiciona metadados
x
a um determinado tipoT
usando a anotaçãoAnnotated[T, x]
. Os metadados adicionados usandoAnnotated
podem ser usados por ferramentas de análise estática ou em tempo de execução. Em tempo de execução, os metadados são armazenados em um atributo__metadata__
.Se uma biblioteca ou ferramenta encontrar uma anotação
Annotated[T, x]
e ela não tiver lógica especial para os metadados, ela deverá ignorar os metadados e simplesmente tratar a anotação comoT
. Dessa forma,Annotated
pode ser útil em códigos que desejarem usar a anotação para propósitos fora do sistema de tipagem estática do Python.Usar
Annotated[T, x]
como um anotação ainda permite a verificação estática do tipo deT
, pois os verificadores de tipo simplesmente ignoram os metadados emx
. Dessa forma, oAnnotated
difere do decorador@no_type_check
, que também pode ser usado para adicionar anotações fora do escopo do sistema de tipagem, mas desativa completamente a verificação de tipos para uma função ou classe.The responsibility of how to interpret the metadata lies with the tool or library encountering an
Annotated
annotation. A tool or library encountering anAnnotated
type can scan through the metadata elements to determine if they are of interest (e.g., usingisinstance()
).- Annotated[<type>, <metadata>]
Here is an example of how you might use
Annotated
to add metadata to type annotations if you were doing range analysis:@dataclass class ValueRange: lo: int hi: int T1 = Annotated[int, ValueRange(-10, 5)] T2 = Annotated[T1, ValueRange(-20, 3)]
Detalhes da sintaxe:
O primeiro argumento de
Annotated
deve ser um tipo válidoMúltiplos elementos de metadados podem ser fornecidos (
Annotated
dá suporte a argumentos variádicos):@dataclass class ctype: kind: str Annotated[int, ValueRange(3, 10), ctype("char")]
It is up to the tool consuming the annotations to decide whether the client is allowed to add multiple metadata elements to one annotation and how to merge those annotations.
Annotated
deve ser subscrito com pelo menos dois argumentos (Annotated[int]
é inválido)A ordem dos elementos de metadados é preservada e é importante em verificações de igualdade:
assert Annotated[int, ValueRange(3, 10), ctype("char")] != Annotated[ int, ctype("char"), ValueRange(3, 10) ]
Os tipos
Annotated
aninhados são achatados. A ordem dos elementos de metadados começa com a anotação mais interna:assert Annotated[Annotated[int, ValueRange(3, 10)], ctype("char")] == Annotated[ int, ValueRange(3, 10), ctype("char") ]
Elementos duplicados de metadata não são removidos:
assert Annotated[int, ValueRange(3, 10)] != Annotated[ int, ValueRange(3, 10), ValueRange(3, 10) ]
Annotated
pode ser usado com apelidos aninhados e apelidos 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]
Annotated
não pode ser usado com umTypeVarTuple
desempacotado:type Variadic[*Ts] = Annotated[*Ts, Ann1] # INVÁLIDO
Isso deve equivaler a:
Annotated[T1, T2, T3, ..., Ann1]
onde
T1
,T2
, etc. sãoTypeVars
. Isso seria inválido: somente um tipo deve ser passado para Annotated.Por padrão,
get_type_hints()
retira os metadados de anotações. Passeinclude_extras=True
para preservar os metadados:>>> 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'>}
Em tempo de execução, os metadados associados a um tipo
Annotated
podem ser recuperados por meio do atributo__metadata__
:>>> from typing import Annotated >>> X = Annotated[int, "very", "important", "metadata"] >>> X typing.Annotated[int, 'very', 'important', 'metadata'] >>> X.__metadata__ ('very', 'important', 'metadata')
Em tempo de execução, se você quiser recuperar o tipo original envolvido por
Annotated
, use o atributo__origin__
:>>> from typing import Annotated, get_origin >>> Password = Annotated[str, "secret"] >>> Password.__origin__ <class 'str'>
Note que usar
get_origin()
retornará o próprioAnnotated
:>>> get_origin(Password) typing.Annotated
Ver também
- PEP 593 - Anotações flexíveis para funções e variáveis
A PEP que introduz
Annotated
à biblioteca padrão.
Adicionado na versão 3.9.
- typing.TypeIs¶
Uma construção especial de tipagem para marcar funções de predicado de tipo definidas pelo usuário.
TypeIs
can be used to annotate the return type of a user-defined type predicate function.TypeIs
only accepts a single type argument. At runtime, functions marked this way should return a boolean and take at least one positional argument.TypeIs
aims 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``. ...
Às vezes, seria conveniente usar uma função booleana definida pelo usuário como um predicado de tipo. Essa função deveria usar
TypeIs[...]
ouTypeGuard
como seu tipo de retorno para alertar o verificador de tipo estático sobre essa intenção.TypeIs
geralmente tem um comportamento mais intuitivo do queTypeGuard
, mas não pode ser usado quando os tipos de entrada e saída são incompatíveis (por exemplo, delist[object]
paralist[int]
) ou quando a função não retornaTrue
para todas as instâncias do tipo restrito.Usar
-> TypeIs[NarrowedType]
informa ao verificador de tipo estático que, para uma determinada função:O valor de retorno é um booleano.
Se o valor de retorno for
True
, o tipo de seu argumento será a interseção entre o tipo original do argumento e oNarrowedType
.Se o valor de retorno for
False
, o tipo de seu argumento será restrito para excluirNarrowedType
.
Por exemplo:
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): # Tipo de ``arg`` é restrito à interseção # de ``Parent`` e ``Child``, o que equivale a # ``Child``. assert_type(arg, Child) else: # Tipo de ``arg`` é restrito para excluir ``Parent``, # então sobrou o tipo ``Unrelated``. assert_type(arg, Unrelated)
The type inside
TypeIs
must be consistent with the type of the function’s argument; if it is not, static type checkers will raise an error. An incorrectly writtenTypeIs
function can lead to unsound behavior in the type system; it is the user’s responsibility to write such functions in a type-safe manner.Se uma função
TypeIs
for um método de classe ou instância, então o tipo emTypeIs
mapeia para o tipo do segundo parâmetro (depois decls
ouself
).Em resumo, a forma
def foo(arg: TypeA) -> TypeIs[TypeB]: ...
, significa que sefoo(arg)
retornaTrue
, entãoarg
é um instância deTypeB
, e se retornaFalse
, não é um instância deTypeB
.TypeIs
também funciona com variáveis de tipo. Para mais informações, consulte a PEP 742 (Restringindo tipos comTypeIs
).Adicionado na versão 3.13.
- typing.TypeGuard¶
Uma construção especial de tipagem para marcar funções de predicado de tipo definidas pelo usuário.
Funções de predicados de tipo são funções definidas pelo usuário que retornam se seu argumento é uma instância de um tipo específico. O
TypeGuard
funciona comoTypeIs
, mas tem efeitos sutilmente diferentes sobre o comportamento da verificação de tipos (veja abaixo).Usar
-> TypeGuard
informa ao verificador de tipo estático que, para uma determinada função:O valor de retorno é um booleano.
Se o valor de retorno for
True
, o tipo de seu argumento é o tipo dentro deTypeGuard
.
TypeGuard
also works with type variables. See PEP 647 for more details.Por exemplo:
def is_str_list(val: list[object]) -> TypeGuard[list[str]]: '''Determina se todos os objetos na lista são strings''' return all(isinstance(x, str) for x in val) def func1(val: list[object]): if is_str_list(val): # Tipo de ``val`` é restrito a ``list[str]``. print(" ".join(val)) else: # Tipo de ``val`` continua sendo ``list[object]``. print("Not a list of strings!")
TypeIs
eTypeGuard
diferem das seguintes maneiras:TypeIs
exige que o tipo restrito seja um subtipo do tipo de entrada, enquanto oTypeGuard
, não. O motivo principal é permitir coisas como restringirlist[object]
alist[str]
, embora este não seja um subtipo daquele, já quelist
é invariante.Quando uma função
TypeGuard
retornaTrue
, os verificadores de tipo restringem o tipo da variável exatamente ao tipoTypeGuard
. Quando uma funçãoTypeIs
retornaTrue
, os verificadores de tipo podem inferir um tipo mais preciso combinando o tipo previamente conhecido da variável com o tipoTypeIs
. (Tecnicamente, isso é conhecido como um tipo de interseção).Quando uma função
TypeGuard
retornaFalse
, os verificadores de tipo não podem restringir o tipo da variável. Quando uma funçãoTypeIs
retornaFalse
, os verificadores de tipo podem restringir o tipo da variável para excluir o tipoTypeIs
.
Adicionado na versão 3.10.
- typing.Unpack¶
Operador de tipagem para marcar conceitualmente um objeto como tendo sido desempacotado.
For example, using the unpack operator
*
on a type variable tuple is equivalent to usingUnpack
to mark the type variable tuple as having been unpacked:Ts = TypeVarTuple('Ts') tup: tuple[*Ts] # Efetivamente faz: tup: tuple[Unpack[Ts]]
In fact,
Unpack
can be used interchangeably with*
in the context oftyping.TypeVarTuple
andbuiltins.tuple
types. You might seeUnpack
being used explicitly in older versions of Python, where*
couldn’t be used in certain places:# In older versions of Python, TypeVarTuple and Unpack # are located in the `typing_extensions` backports package. from typing_extensions import TypeVarTuple, Unpack Ts = TypeVarTuple('Ts') tup: tuple[*Ts] # Syntax error on Python <= 3.10! tup: tuple[Unpack[Ts]] # Semantically equivalent, and backwards-compatible
Unpack
também pode ser usado comtyping.TypedDict
para a tipagem de**kwargs
em uma assinatura de função:from typing import TypedDict, Unpack class Movie(TypedDict): name: str year: int # Esta função espera dois argumentos nomeados: `name` de tipo `str` # e `year` de tipo `int`. def foo(**kwargs: Unpack[Movie]): ...
Consulte PEP 692 para obter mais detalhes sobre como usar
Unpack
para tipagem de**kwargs
.Adicionado na versão 3.11.
Criando tipos genéricos e apelidos de tipo¶
The following classes should not be used directly as annotations. Their intended purpose is to be building blocks for creating generic types and type aliases.
Esses objetos podem ser criados por meio de sintaxe especial (listas de parâmetros de tipo e a instrução type
). Para compatibilidade com Python 3.11 e versões anteriores, eles também podem ser criados sem a sintaxe dedicada, como documentado abaixo.
- class typing.Generic¶
Classe base abstrata para tipos genéricos
Normalmente, um tipo genérico é declarado adicionando-se uma lista de parâmetros de tipo após o nome da classe:
class Mapping[KT, VT]: def __getitem__(self, key: KT) -> VT: ... # Etc.
Essa classe herda implicitamente de
Generic
. A semântica em tempo de execução dessa sintaxe é discutida na Referência da Linguagem.Esta classe pode ser utilizada como segue:
def lookup_name[X, Y](mapping: Mapping[X, Y], key: X, default: Y) -> Y: try: return mapping[key] except KeyError: return default
Aqui os colchetes depois no nome da função indica uma função genérica.
For backwards compatibility, generic classes can also be declared by explicitly inheriting from
Generic
. In this case, the type parameters must be declared separately:KT = TypeVar('KT') VT = TypeVar('VT') class Mapping(Generic[KT, VT]): def __getitem__(self, key: KT) -> VT: ... # Etc.
- class typing.TypeVar(name, *constraints, bound=None, covariant=False, contravariant=False, infer_variance=False, default=typing.NoDefault)¶
Tipo variável.
The preferred way to construct a type variable is via the dedicated syntax for generic functions, generic classes, and generic type aliases:
class Sequence[T]: # T é um TypeVar ...
This syntax can also be used to create bound and constrained type variables:
class StrSequence[S: str]: # S is a TypeVar bound to str ... class StrOrBytesSequence[A: (str, bytes)]: # A is a TypeVar constrained to str or bytes ...
However, if desired, reusable type variables can also be constructed manually, like so:
T = TypeVar('T') # Can be anything S = TypeVar('S', bound=str) # Can be any subtype of str A = TypeVar('A', str, bytes) # Must be exactly str or bytes
Type variables exist primarily for the benefit of static type checkers. They serve as the parameters for generic types as well as for generic function and type alias definitions. See
Generic
for more information on generic types. Generic functions work as follows:def repeat[T](x: T, n: int) -> Sequence[T]: """Return a list containing n references to x.""" return [x]*n def print_capitalized[S: str](x: S) -> S: """Print x capitalized, and return x.""" print(x.capitalize()) return x def concatenate[A: (str, bytes)](x: A, y: A) -> A: """Add two strings or bytes objects together.""" return x + y
Note that type variables can be bound, constrained, or neither, but cannot be both bound and constrained.
The variance of type variables is inferred by type checkers when they are created through the type parameter syntax or when
infer_variance=True
is passed. Manually created type variables may be explicitly marked covariant or contravariant by passingcovariant=True
orcontravariant=True
. By default, manually created type variables are invariant. See PEP 484 and PEP 695 for more details.Bound type variables and constrained type variables have different semantics in several important ways. Using a bound type variable means that the
TypeVar
will 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
Type variables can be bound to concrete types, abstract types (ABCs or protocols), and even unions 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
Using a constrained type variable, however, means that the
TypeVar
can only ever be solved as being exactly one of the constraints given: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
Em tempo de execução,
isinstance(x, T)
levantaráTypeError
.- __name__¶
The name of the type variable.
- __covariant__¶
Whether the type var has been explicitly marked as covariant.
- __contravariant__¶
Whether the type var has been explicitly marked as contravariant.
- __infer_variance__¶
Whether the type variable’s variance should be inferred by type checkers.
Adicionado na versão 3.12.
- __bound__¶
The bound of the type variable, if any.
Alterado na versão 3.12: For type variables created through type parameter syntax, the bound is evaluated only when the attribute is accessed, not when the type variable is created (see Avaliação preguiçosa).
- __constraints__¶
A tuple containing the constraints of the type variable, if any.
Alterado na versão 3.12: For type variables created through type parameter syntax, the constraints are evaluated only when the attribute is accessed, not when the type variable is created (see Avaliação preguiçosa).
- __default__¶
The default value of the type variable, or
typing.NoDefault
if it has no default.Adicionado na versão 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.NoDefault
singleton, except that it does not force evaluation of the lazily evaluated default value.Adicionado na versão 3.13.
Alterado na versão 3.12: Type variables can now be declared using the type parameter syntax introduced by PEP 695. The
infer_variance
parameter was added.Alterado na versão 3.13: Adiciona suporte a valores padrão.
- class typing.TypeVarTuple(name, *, default=typing.NoDefault)¶
Type variable tuple. A specialized form of type variable that enables variadic generics.
Type variable tuples can be declared in type parameter lists using a single asterisk (
*
) before the name:def move_first_element_to_last[T, *Ts](tup: tuple[T, *Ts]) -> tuple[*Ts, T]: return (*tup[1:], tup[0])
Ou invocando o construtor
TypeVarTuple
explicitamente:T = TypeVar("T") Ts = TypeVarTuple("Ts") def move_first_element_to_last(tup: tuple[T, *Ts]) -> tuple[*Ts, T]: return (*tup[1:], tup[0])
A normal type variable enables parameterization with a single type. A type variable tuple, in contrast, allows parameterization with an arbitrary number of types by acting like an arbitrary number of type variables wrapped in a tuple. For example:
# T é limitado a int, Ts é limitado a () # Valor retornado é (1,), que tem tipo tuple[int] move_first_element_to_last(tup=(1,)) # T é limitado a int, Ts é limitado a (str,) # Valor retornado é ('spam', 1), que tem tipo tuple[str, int] move_first_element_to_last(tup=(1, 'spam')) # T é limitado a int, Ts é limitado a (str, float) # Valor retornado é ('spam', 3.0, 1), que tem tipo tuple[str, float, int] move_first_element_to_last(tup=(1, 'spam', 3.0)) # Isso é um erro para o verificador de tipos (e falha em tempo de execução) # pois tuple[()] não é compatível com tuple[T, *Ts] # (pelo menos um elemento é necessário) move_first_element_to_last(tup=())
Note the use of the unpacking operator
*
intuple[T, *Ts]
. Conceptually, you can think ofTs
as a tuple of type variables(T1, T2, ...)
.tuple[T, *Ts]
would then becometuple[T, *(T1, T2, ...)]
, which is equivalent totuple[T, T1, T2, ...]
. (Note that in older versions of Python, you might see this written usingUnpack
instead, asUnpack[Ts]
.)Type variable tuples must always be unpacked. This helps distinguish type variable tuples from normal type variables:
x: Ts # Inválido x: tuple[Ts] # Inválido x: tuple[*Ts] # O jeito correto
Type variable tuples can be used in the same contexts as normal type variables. For example, in class definitions, arguments, and return types:
class Array[*Shape]: def __getitem__(self, key: tuple[*Shape]) -> float: ... def __abs__(self) -> "Array[*Shape]": ... def get_shape(self) -> tuple[*Shape]: ...
Type variable tuples can be happily combined with normal type variables:
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
However, note that at most one type variable tuple may appear in a single list of type arguments or type parameters:
x: tuple[*Ts, *Ts] # Inválido class Array[*Shape, *Shape]: # Inválido pass
Finally, an unpacked type variable tuple can be used as the type annotation of
*args
:def call_soon[*Ts]( callback: Callable[[*Ts], None], *args: *Ts ) -> None: ... callback(*args)
In contrast to non-unpacked annotations of
*args
- e.g.*args: int
, which would specify that all arguments areint
-*args: *Ts
enables reference to the types of the individual arguments in*args
. Here, this allows us to ensure the types of the*args
passed tocall_soon
match the types of the (positional) arguments ofcallback
.See PEP 646 for more details on type variable tuples.
- __name__¶
The name of the type variable tuple.
- __default__¶
The default value of the type variable tuple, or
typing.NoDefault
if it has no default.Adicionado na versão 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.NoDefault
singleton, except that it does not force evaluation of the lazily evaluated default value.Adicionado na versão 3.13.
Adicionado na versão 3.11.
Alterado na versão 3.12: Type variable tuples can now be declared using the type parameter syntax introduced by PEP 695.
Alterado na versão 3.13: Adiciona suporte a valores padrão.
- class typing.ParamSpec(name, *, bound=None, covariant=False, contravariant=False, default=typing.NoDefault)¶
Parameter specification variable. A specialized version of type variables.
Em listas de parâmetros de tipo as especificações de parâmetros podem ser declaradas com dois asteriscos (
**
):type IntFunc[**P] = Callable[P, int]
Para compatibilidade com Python 3.11 e versões anteriores, os objetos
ParamSpec
também podem ser criados da seguinte forma:P = ParamSpec('P')
Parameter specification variables exist primarily for the benefit of static type checkers. They are used to forward the parameter types of one callable to another callable – a pattern commonly found in higher order functions and decorators. They are only valid when used in
Concatenate
, or as the first argument toCallable
, or as parameters for user-defined Generics. SeeGeneric
for more information on generic types.For example, to add basic logging to a function, one can create a decorator
add_logging
to log function calls. The parameter specification variable tells the type checker that the callable passed into the decorator and the new callable returned by it have inter-dependent type parameters: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 aTypeVar
with boundCallable[..., Any]
. However this causes two problems:O verificador de tipos não consegue verificar a função
inner
, porque*args
e**kwargs
precisam ter tipoAny
.cast()
may be required in the body of theadd_logging
decorator when returning theinner
function, or the static type checker must be told to ignore thereturn inner
.
- args¶
- kwargs¶
Como
ParamSpec
capturar tanto parâmetros posicionais quanto parâmetros nomeados,P.args
eP.kwargs
podem ser usados para dividir umParamSpec
em seus componentes.P.args
representa a tupla de parâmetros posicionais em uma determinada chamada e só deve ser usada para anotar*args
.P.kwargs
representa o mapeamento de parâmetros nomeados para seus valores em uma determinada chamada, e só deve ser usado para anotar**kwargs
. Ambos os atributos exigem que o parâmetro anotado esteja em escopo. Em tempo de execução,P.args
eP.kwargs
são instâncias, respectivamente, deParamSpecArgs
eParamSpecKwargs
.
- __name__¶
O nome da especificação de parâmetros.
- __default__¶
O valor padrão da especificação de parâmetro, ou
typing.NoDefault
se não tiver padrão.Adicionado na versão 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.NoDefault
singleton, except that it does not force evaluation of the lazily evaluated default value.Adicionado na versão 3.13.
Variáveis de especificação de parâmetros criadas com
covariant=True
oucontravariant=True
podem ser usadas para declarar tipos genéricos covariantes ou contravariantes. O argumentobound
também é aceito, semelhante aoTypeVar
. Porém, a semântica real dessas palavras reservadas ainda não foi decidida.Adicionado na versão 3.10.
Alterado na versão 3.12: Especificações de parâmetros agora podem ser declaradas usando a sintaxe de parâmetros de tipo introduzido pela PEP 695.
Alterado na versão 3.13: Adiciona suporte a valores padrão.
Nota
Somente variáveis de especificação de parâmetro definidas em escopo global podem ser serializadas com pickle.
Ver também
PEP 612 – Variáveis de especificação de parâmetro (a PEP que introduz
ParamSpec
eConcatenate
)
- typing.ParamSpecArgs¶
- typing.ParamSpecKwargs¶
Arguments and keyword arguments attributes of a
ParamSpec
. TheP.args
attribute of aParamSpec
is an instance ofParamSpecArgs
, andP.kwargs
is an instance ofParamSpecKwargs
. They are intended for runtime introspection and have no special meaning to static type checkers.Chamar
get_origin()
em qualquer um desses objetos fará retornará oParamSpec
original:>>> from typing import ParamSpec, get_origin >>> P = ParamSpec("P") >>> get_origin(P.args) is P True >>> get_origin(P.kwargs) is P True
Adicionado na versão 3.10.
- class typing.TypeAliasType(name, value, *, type_params=())¶
O tipo de apelidos de tipo criados pela instrução
type
.Exemplo:
>>> type Alias = int >>> type(Alias) <class 'typing.TypeAliasType'>
Adicionado na versão 3.12.
- __name__¶
O nome do apelido de tipo:
>>> type Alias = int >>> Alias.__name__ 'Alias'
- __module__¶
O módulo na qual o apelido de tipo foi definido:
>>> type Alias = int >>> Alias.__module__ '__main__'
- __type_params__¶
Os parâmetros de tipo do apelido de tipo, ou um tupla vazia se o apelido não for genérico:
>>> type ListOrSet[T] = list[T] | set[T] >>> ListOrSet.__type_params__ (T,) >>> type NotGeneric = int >>> NotGeneric.__type_params__ ()
- __value__¶
The type alias’s value. This is lazily evaluated, so names used in the definition of the alias are not resolved until the
__value__
attribute is accessed:>>> type Mutually = Recursive >>> type Recursive = Mutually >>> Mutually Mutually >>> Recursive Recursive >>> Mutually.__value__ Recursive >>> Recursive.__value__ Mutually
Outras diretivas especiais¶
These functions and classes should not be used directly as annotations. Their intended purpose is to be building blocks for creating and declaring types.
- class typing.NamedTuple¶
Typed version of
collections.namedtuple()
.Uso:
class Employee(NamedTuple): name: str id: int
Isso equivale a:
Employee = collections.namedtuple('Employee', ['name', 'id'])
Para dar um valor padrão a um campo, você pode atribuir um valor a ele no corpo da classe:
class Employee(NamedTuple): name: str id: int = 3 employee = Employee('Guido') assert employee.id == 3
Campos com valores padrão devem vir depois de quaisquer campos sem valores padrão.
The resulting class has an extra attribute
__annotations__
giving a dict that maps the field names to the field types. (The field names are in the_fields
attribute and the default values are in the_field_defaults
attribute, both of which are part of thenamedtuple()
API.)Subclasses de
NamedTuple
também podem ter docstrings e métodos:class Employee(NamedTuple): """Representa um funcionário.""" name: str id: int = 3 def __repr__(self) -> str: return f'<Employee {self.name}, id={self.id}>'
Subclasses de ``NamedTuple``podem ser genéricas:
class Group[T](NamedTuple): key: T group: list[T]
Backward-compatible usage:
# 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)])
Alterado na versão 3.6: Adiciona suporte à sintaxe de anotação de variáveis da PEP 526.
Alterado na versão 3.6.1: Adiciona suporte a valores padrão, métodos, e docstrings.
Alterado na versão 3.8: Os atributos
_field_types
e__annotations__
agora são dicionários regulares em vez de instâncias deOrderedDict
.Alterado na versão 3.9: Remove o atributo
_field_types
em favor do atributo mais padrão__annotations__
que tem as mesmas informações.Alterado na versão 3.11: Adicionado suporte a namedtuples genéricas.
Deprecated since version 3.13, will be removed in version 3.15: A sintaxe de argumentos nomeados não documentados para criar classes NamedTuple (
NT = NamedTuple("NT", x=int)
) está descontinuado e será proibido na versão 3.15. Em vez disso, use a sintaxe baseada em classes ou a sintaxe funcional.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. PassingNone
to 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): pass
orNT = NamedTuple("NT", [])
.
- class typing.NewType(name, tp)¶
Helper class to create low-overhead distinct types.
Um tipo
NewType
é considerado um tipo distinto por um verificador de tipos. Porém, em tempo de execução, chamar ``NewType``retorna seu argumento sem modificações.Uso:
UserId = NewType('UserId', int) # Declare o NewType "UserId" first_user = UserId(1) # "UserId" retorna o argumento inalterado em tempo de execução
- __module__¶
O endereço módulo no qual o novo tipo é definido.
- __name__¶
O nome do novo tipo.
- __supertype__¶
O tipo na qual o novo tipo é baseado.
Adicionado na versão 3.5.2.
Alterado na versão 3.10:
NewType
agora é uma classe em vez de uma função.
- class typing.Protocol(Generic)¶
Classe base para classes de protocolo.
Classes de protocolo são definidas assim:
class Proto(Protocol): def meth(self) -> int: ...
Essas classes são usadas principalmente com verificadores de tipo estático que reconhecem a subtipagem estrutural (tipagem pato estática). Por exemplo,:
class C: def meth(self) -> int: return 0 def func(x: Proto) -> int: return x.meth() func(C()) # Passa na verificação de tipos
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.Classes de protocolo podem ser genéricas. Por exemplo:
class GenProto[T](Protocol): def meth(self) -> T: ...
Em códigos que precisam ser compatíveis com Python 3.11 ou versões anteriores, protocolos genéricos podem ser escritos da seguinte forma:
T = TypeVar("T") class GenProto(Protocol[T]): def meth(self) -> T: ...
Adicionado na versão 3.8.
- @typing.runtime_checkable¶
Marca uma classe de protocolo como um protocolo de tempo de execução.
Such a protocol can be used with
isinstance()
andissubclass()
. This raisesTypeError
when applied to a non-protocol class. This allows a simple-minded structural check, very similar to “one trick ponies” incollections.abc
such 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)
Nota
runtime_checkable()
will check only the presence of the required methods or attributes, not their type signatures or types. For example,ssl.SSLObject
is a class, therefore it passes anissubclass()
check against Callable. However, thessl.SSLObject.__init__
method exists only to raise aTypeError
with a more informative message, therefore making it impossible to call (instantiate)ssl.SSLObject
.Nota
An
isinstance()
check against a runtime-checkable protocol can be surprisingly slow compared to anisinstance()
check against a non-protocol class. Consider using alternative idioms such ashasattr()
calls for structural checks in performance-sensitive code.Adicionado na versão 3.8.
Alterado na versão 3.12: The internal implementation of
isinstance()
checks against runtime-checkable protocols now usesinspect.getattr_static()
to look up attributes (previously,hasattr()
was used). As a result, some objects which used to be considered instances of a runtime-checkable protocol may no longer be considered instances of that protocol on Python 3.12+, and vice versa. Most users are unlikely to be affected by this change.Alterado na versão 3.12: The members of a runtime-checkable protocol are now considered “frozen” at runtime as soon as the class has been created. Monkey-patching attributes onto a runtime-checkable protocol will still work, but will have no impact on
isinstance()
checks comparing objects to the protocol. See “What’s new in Python 3.12” for more details.
- class typing.TypedDict(dict)¶
Uma construção especial para adicionar dicas de tipo a um dicionário. Em tempo de execução, é um simples
dict
.TypedDict
declares a dictionary type that expects all of its instances to have a certain set of keys, where each key is associated with a value of a consistent type. This expectation is not checked at runtime but is only enforced by type checkers. Usage:class Point2D(TypedDict): x: int y: int label: str a: Point2D = {'x': 1, 'y': 2, 'label': 'good'} # OK b: Point2D = {'z': 3, 'label': 'bad'} # Falha na verificação de tipos assert Point2D(x=1, y=2, label='first') == dict(x=1, y=2, label='first')
Um modo alternativo de criar um
TypedDict
é usando a sintaxe de chamada de função. O segundo argumento deve ser umdict
:Point2D = TypedDict('Point2D', {'x': int, 'y': int, 'label': str})
Esta sintaxe funcional permite definirmos chaves usando identificadores inválidos, por exemplo, por serem palavras-chave ou conterem hífens:
# levanta SyntaxError class Point2D(TypedDict): in: int # 'in' é uma palavra-chave x-y: int # nome com hífens # OK, sintaxe funcional Point2D = TypedDict('Point2D', {'in': int, 'x-y': int})
Por padrão, todas as chaves devem estar presentes em um
TypedDict
. É possível marcar chaves individuais como não obrigatórias usandoNotRequired
:class Point2D(TypedDict): x: int y: int label: NotRequired[str] # Sintaxe alternativa Point2D = TypedDict('Point2D', {'x': int, 'y': int, 'label': NotRequired[str]})
Isso significa que um
TypedDict
Point2D
pode ter a chavelabel
omitida.Também é possível marcar todas as chaves como não necessárias por padrão, especificando a totalidade como
False
:class Point2D(TypedDict, total=False): x: int y: int # Sintaxe alternativa Point2D = TypedDict('Point2D', {'x': int, 'y': int}, total=False)
Isso significa que um
Point2D
TypedDict
pode ter qualquer uma de suas chaves omitidas. Espera-se que um verificador de tipos apenas permita os literaisFalse
ouTrue
como valores do argumentototal
.True
é o padrão, e todos os itens definidos no corpo da classe tornam-se obrigatórios.As chaves individuais de um
TypedDict
comtotal=False
podem ser marcadas conforme necessário usandoRequired
:class Point2D(TypedDict, total=False): x: Required[int] y: Required[int] label: str # Sintaxe alternativa Point2D = TypedDict('Point2D', { 'x': Required[int], 'y': Required[int], 'label': str }, total=False)
É possível que um tipo
TypedDict
herde de um ou mais tiposTypedDict
usando a sintaxe baseada em classes. Modo de usar:class Point3D(Point2D): z: int
Point3D
tem três itens:x
,y
ez
. Equivale a esta definição:class Point3D(TypedDict): x: int y: int z: int
Um
TypedDict
não pode herdar de uma classe nãoTypedDict
, excetoGeneric
. Por exemplo:class X(TypedDict): x: int class Y(TypedDict): y: int class Z(object): pass # Uma classe não TypedDict class XY(X, Y): pass # OK class XZ(X, Z): pass # levanta TypeError
Um
TypedDict
pode ser genérico:class Group[T](TypedDict): key: T group: list[T]
Para criar um
TypedDict
genérico que seja compatível com Python 3.11 ou inferior, herde deGeneric
explicitamente:T = TypeVar("T") class Group(TypedDict, Generic[T]): key: T group: list[T]
Um
TypedDict
pode ser introspeccionado por meio de dicionários de anotações (consulte Boas práticas para anotações para obter mais informações sobre as melhores práticas de anotações),__total__
,__required_keys__
e__optional_keys__
.- __total__¶
Point2D.__total__
fornece o valor do argumentototal
. Exemplo:>>> 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
Esse atributo reflete apenas o valor do argumento
total
para a classeTypedDict
atual, e não que a classe é semanticamente total. Por exemplo, umTypedDict
com__total__
definido comoTrue
pode ter chaves marcadas comNotRequired
, ou pode herdar de outroTypedDict
comtotal=False
. Portanto, geralmente é melhor usar__required_keys__
e__optional_keys__
para introspecção.
- __required_keys__¶
Adicionado na versão 3.9.
- __optional_keys__¶
Point2D.__required_keys__
ePoint2D.__optional_keys__
retornam objetosfrozenset
contendo chaves obrigatórias e opcionais, respectivamente.As chaves marcadas com
Required
sempre aparecerão em__required_keys__
e as chaves marcadas comNotRequired
sempre aparecerão em__optional_keys__
.For backwards compatibility with Python 3.10 and below, it is also possible to use inheritance to declare both required and non-required keys in the same
TypedDict
. This is done by declaring aTypedDict
with one value for thetotal
argument and then inheriting from it in anotherTypedDict
with a different value fortotal
:>>> 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
Adicionado na versão 3.9.
Nota
Se
from __future__ import annotations
for usado ou se anotações forem fornecidas como strings, as anotações não serão avaliadas quando oTypedDict
for definido. Portanto, a introspecção em tempo de execução da qual__required_keys__
e__optional_keys__
dependem pode não funcionar corretamente, e os valores dos atributos podem estar incorretos.
O suporte para
ReadOnly
está refletido nos seguintes atributos:- __readonly_keys__¶
Um
frozenset
contendo os nomes de todas as chaves somente para leitura. As chaves são somente para leitura se tiverem o qualificadorReadOnly
.Adicionado na versão 3.13.
- __mutable_keys__¶
Um
frozenset
contendo os nomes de todas as chaves mutáveis. As chaves são mutáveis se não tiverem o qualificadorReadOnly
.Adicionado na versão 3.13.
Consulte PEP 589 para obter mais exemplos e regras detalhadas sobre o uso de
TypedDict
.Adicionado na versão 3.8.
Alterado na versão 3.11: Adicionado suporte para marcar chaves individuais como
Required
ouNotRequired
. Consulte PEP 655.Alterado na versão 3.11: Adicionado suporte para
TypedDict
s genéricos.Alterado na versão 3.13: Removeu suporte para o método de argumento nomeado de criar
TypedDict
s.Alterado na versão 3.13: Adiciona suporte ao qualificador
ReadOnly
.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. PassingNone
to 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): pass
orTD = TypedDict("TD", {})
.
Protocolos¶
Os protocolos a seguir são fornecidos pelo módulo typing. Todos são decorados com @runtime_checkable
.
- class typing.SupportsAbs¶
Um ABC com um método abstrato
__abs__
que é covariante em seu tipo de retorno.
- class typing.SupportsBytes¶
Um ABC com um método abstrato
__bytes__
.
- class typing.SupportsComplex¶
Um ABC com um método abstrato
__complex__
.
- class typing.SupportsFloat¶
Um ABC com um método abstrato
__float__
.
- class typing.SupportsIndex¶
Um ABC com um método abstrato
__index__
.Adicionado na versão 3.8.
- class typing.SupportsInt¶
Um ABC com um método abstrato
__int__
.
- class typing.SupportsRound¶
Uma ABC com um método abstrato
__round__
que é covariante em seu tipo de retorno.
ABCs para trabalhar com E/S¶
Funções e decoradores¶
- typing.cast(typ, val)¶
Define um valor para um tipo.
This returns the value unchanged. To the type checker this signals that the return value has the designated type, but at runtime we intentionally don’t check anything (we want this to be as fast as possible).
- typing.assert_type(val, typ, /)¶
Pede para um verificador de tipo estático confirmar se val tem tipo inferido typ.
At runtime this does nothing: it returns the first argument unchanged with no checks or side effects, no matter the actual type of the argument.
When a static type checker encounters a call to
assert_type()
, it emits an error if the value is not of the specified type:def greet(name: str) -> None: assert_type(name, str) # OK, o tipo inferido de `name` é `str` assert_type(name, int) # erro no verificador de tipos
Esse função é útil para garantir que o verificador de tipos entende um script conforme as intenções do desenvolvedor:
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)
Adicionado na versão 3.11.
- typing.assert_never(arg, /)¶
Pede ao verificador de tipo estático para confirmar se uma linha de código é inalcançável.
Exemplo:
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)
Here, the annotations allow the type checker to infer that the last case can never execute, because
arg
is either anint
or astr
, and both options are covered by earlier cases.If a type checker finds that a call to
assert_never()
is reachable, it will emit an error. For example, if the type annotation forarg
was insteadint | str | float
, the type checker would emit an error pointing out thatunreachable
is of typefloat
. For a call toassert_never
to pass type checking, the inferred type of the argument passed in must be the bottom type,Never
, and nothing else.Em tempo de execução, essa função levanta uma exceção quando chamada.
Ver também
Código inalcançável e verificação exaustiva têm mais informações sobre a verificação exaustiva com a tipagem estática.
Adicionado na versão 3.11.
- typing.reveal_type(obj, /)¶
Pede para um verificador de tipo estático revelar o tipo inferido de uma expressão.
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) # O tipo revelado é "builtins.int"
Isso pode ser útil quando você deseja depurar como o verificador de tipos lida com um determinado trecho de código.
At runtime, this function prints the runtime type of its argument to
sys.stderr
and returns the argument unchanged (allowing the call to be used within an expression):x = reveal_type(1) # exibe "Runtime type is int" print(x) # exibe "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.Adicionado na versão 3.11.
- @typing.dataclass_transform(*, eq_default=True, order_default=False, kw_only_default=False, frozen_default=False, field_specifiers=(), **kwargs)¶
Um decorador que marca um objeto como tendo comportamento similar a uma
dataclass
.dataclass_transform
may be used to decorate a class, metaclass, or a function that is itself a decorator. The presence of@dataclass_transform()
tells a static type checker that the decorated object performs runtime “magic” that transforms a class in a similar way to@dataclasses.dataclass
.Exemplo de uso com a função decoradora:
@dataclass_transform() def create_model[T](cls: type[T]) -> type[T]: ... return cls @create_model class CustomerModel: id: int name: str
Em uma classe base:
@dataclass_transform() class ModelBase: ... class CustomerModel(ModelBase): id: int name: str
Em uma metaclasse:
@dataclass_transform() class ModelMeta(type): ... class ModelBase(metaclass=ModelMeta): ... class CustomerModel(ModelBase): id: int name: str
The
CustomerModel
classes defined above will be treated by type checkers similarly to classes created with@dataclasses.dataclass
. For example, type checkers will assume these classes have__init__
methods that acceptid
andname
.The decorated class, metaclass, or function may accept the following bool arguments which type checkers will assume have the same effect as they would have on the
@dataclasses.dataclass
decorator:init
,eq
,order
,unsafe_hash
,frozen
,match_args
,kw_only
, andslots
. It must be possible for the value of these arguments (True
orFalse
) to be statically evaluated.Os argumentos do decorador ``dataclass_transform``podem ser usados para personalizar os comportamentos padrão da classe, metaclasse, ou função decorada:
- Parâmetros:
eq_default (bool) – Indicates whether the
eq
parameter is assumed to beTrue
orFalse
if it is omitted by the caller. Defaults toTrue
.order_default (bool) – Indicates whether the
order
parameter is assumed to beTrue
orFalse
if it is omitted by the caller. Defaults toFalse
.kw_only_default (bool) – Indicates whether the
kw_only
parameter is assumed to beTrue
orFalse
if it is omitted by the caller. Defaults toFalse
.frozen_default (bool) –
Indicates whether the
frozen
parameter is assumed to beTrue
orFalse
if it is omitted by the caller. Defaults toFalse
.Adicionado na versão 3.12.
field_specifiers (tuple[Callable[..., Any], ...]) – Especifica uma lista estática de classes ou funções compatíveis que descrevem campos, semelhante a
dataclasses.field()
. O valor padrão é()
.**kwargs (Any) – Outros argumentos nomeados arbitrários são aceitos para permitir possíveis futuras extensões.
Verificadores de tipo reconhecem os seguintes parâmetros opcionais em especificadores de campos:
Parâmetros reconhecidos para especificadores de campos¶ Nome do parâmetro
Descrição
init
Indica se o campo deve ser incluído no método
__init__
sintetizado. Se não for especificado, o valor padrão deinit
éTrue
.default
Fornece o valor padrão do campo.
default_factory
Provides a runtime callback that returns the default value for the field. If neither
default
nordefault_factory
are specified, the field is assumed to have no default value and must be provided a value when the class is instantiated.factory
Um apelido para o parâmetro
default_factory
em especificadores de campos.kw_only
Indica se o campo deve ser marcado como somente-nomeado. Se verdadeiro, o campo será somente-nomeado. Se falso, não será somente-nomeado. Se não for especificado, será usado o valor do parâmetro
kw_only
do objeto decorado comdataclass_transform
ou, se este não for especificado, será usado o valor dekw_only_default
nodataclass_transform
.alias
Fornece um nome alternativo para o campo. Esse nome alternativo é usado no método
__init__
sintetizado.At runtime, this decorator records its arguments in the
__dataclass_transform__
attribute on the decorated object. It has no other runtime effect.Consulte PEP 681 para mais detalhes.
Adicionado na versão 3.11.
- @typing.overload¶
Decorador para criar funções e métodos sobrecarregados.
The
@overload
decorator allows describing functions and methods that support multiple different combinations of argument types. A series of@overload
-decorated definitions must be followed by exactly one non-@overload
-decorated definition (for the same function/method).@overload
-decorated definitions are for the benefit of the type checker only, since they will be overwritten by the non-@overload
-decorated definition. The non-@overload
-decorated definition, meanwhile, will be used at runtime but should be ignored by a type checker. At runtime, calling an@overload
-decorated function directly will raiseNotImplementedError
.An example of overload that gives a more precise type than can be expressed using a union or a type variable:
@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
Consulte PEP 484 para mais detalhes e uma comparação com outras semânticas de tipagem.
Alterado na versão 3.11: Funções sobrecarregadas agora podem ser introspeccionadas em tempo de execução usando
get_overloads()
.
- typing.get_overloads(func)¶
Retorna uma sequência de
@overload
-definições decoradas para func.func é o objeto função para a implementação da função sobrecarregada. Por exemplo, dada a definição de
process
na documentação de@sobrecarga
,get_overloads(process)
retornará uma sequência de três objetos função para as três sobrecargas definidas. Se for chamada em uma função sem sobrecargas,get_overloads()
retornará uma sequência vazia.A função
get_overloads()
pode ser usada em tempo de execução para introspecção de uma função sobrecarregada.Adicionado na versão 3.11.
- typing.clear_overloads()¶
Apaga todas as sobrecargas registradas no registro interno.
Isso pode ser usado para recuperar a memória usada pelo registro.
Adicionado na versão 3.11.
- @typing.final¶
Um decorador para indicar métodos e classes finais.
Decorating a method with
@final
indicates to a type checker that the method cannot be overridden in a subclass. Decorating a class with@final
indicates that it cannot be subclassed.Por exemplo:
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 ...
Não há verificação em tempo de execução dessas propriedades. Veja PEP 591 para mais detalhes.
Adicionado na versão 3.8.
Alterado na versão 3.11: The decorator will now attempt to set a
__final__
attribute toTrue
on the decorated object. Thus, a check likeif getattr(obj, "__final__", False)
can be used at runtime to determine whether an objectobj
has been marked as final. If the decorated object does not support setting attributes, the decorator returns the object unchanged without raising an exception.
- @typing.no_type_check¶
Decorador para indicar que anotações não são dicas de tipo.
This works as a class or function decorator. With a class, it applies recursively to all methods and classes defined in that class (but not to methods defined in its superclasses or subclasses). Type checkers will ignore all annotations in a function or class with this decorator.
@no_type_check
modifica o objeto decorado internamente.
- @typing.no_type_check_decorator¶
Decorador para dar a outro decorador o efeito
no_type_check()
.Isso envolve o decorador com algo que envolve a função decorada em
no_type_check()
.Deprecated since version 3.13, will be removed in version 3.15: Nenhum verificador de tipos jamais adicionou suporte para
@no_type_check_decorator
. Portanto, ele está descontinuado e será removido no Python 3.15.
- @typing.override¶
Decorador para indicar que um método em uma subclasse deve sobrecarregar um método ou atributo em uma superclasse.
Type checkers should emit an error if a method decorated with
@override
does not, in fact, override anything. This helps prevent bugs that may occur when a base class is changed without an equivalent change to a child class.Por exemplo:
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 ...
Não há verificação desta propriedade em tempo de execução.
The decorator will attempt to set an
__override__
attribute toTrue
on the decorated object. Thus, a check likeif getattr(obj, "__override__", False)
can be used at runtime to determine whether an objectobj
has been marked as an override. If the decorated object does not support setting attributes, the decorator returns the object unchanged without raising an exception.Consulte PEP 698 para obter mais detalhes.
Adicionado na versão 3.12.
- @typing.type_check_only¶
Decorador para marcar uma classe ou função como indisponível em tempo de execução.
This decorator is itself not available at runtime. It is mainly intended to mark classes that are defined in type stub files if an implementation returns an instance of a private class:
@type_check_only class Response: # private or not available at runtime code: int def get_header(self, name: str) -> str: ... def fetch_response() -> Response: ...
Observe que retornar instâncias de classes privadas não é recomendado. Normalmente, é preferível tornar essas classes públicas.
Introspection helpers¶
- typing.get_type_hints(obj, globalns=None, localns=None, include_extras=False)¶
Retorna um dicionário contendo dicas de tipo para uma função, método, módulo ou objeto classe.
Geralmente é o mesmo que
obj.__annotations__
, mas esta função faz as seguintes alterações no dicionário de anotações:Forward references encoded as string literals or
ForwardRef
objects 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.None
é substituído portypes.NoneType
.Se
@no_type_check
tiver sido aplicada a obj, um dicionário vazio será retornado.If obj is a class
C
, the function returns a dictionary that merges annotations fromC
’s base classes with those onC
directly. 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
(seeAnnotated
for more information).
Veja também
inspect.get_annotations()
, uma função de nível mais baixo que retorna anotações mais diretamente.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
.Alterado na versão 3.9: Adiciona o parâmetro
include_extras
como parte da PEP 593. Consulte a documentação emAnnotated
para obter mais informações.Alterado na versão 3.11: Previously,
Optional[t]
was added for function and method annotations if a default value equal toNone
was set. Now the annotation is returned unchanged.
- typing.get_origin(tp)¶
Obtenha o versão sem subscrição de um tipo: para um objeto cujo tipo tem a forma
X[Y, Z, ...]
, retornaX
.Se
X
for um apelido do módulo typing para uma classe embutida ou classe decollections
, ele será normalizado para a classe original. SeX
for uma instância deParamSpecArgs
ouParamSpecKwargs
, retorna oParamSpec
subjacente. RetornaNone
para objetos incompatíveis.Exemplos:
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
Adicionado na versão 3.8.
- typing.get_args(tp)¶
Obtenha os argumentos de tipos com todas as substituições realizadas: para um objeto cujo tipo tem a forma
X[Y, Z, ...]
, retorna(Y, Z, ...)
.If
X
is a union orLiteral
contained in another generic type, the order of(Y, Z, ...)
may be different from the order of the original arguments[Y, Z, ...]
due to type caching. Return()
for unsupported objects.Exemplos:
assert get_args(int) == () assert get_args(Dict[int, str]) == (int, str) assert get_args(Union[int, str]) == (int, str)
Adicionado na versão 3.8.
- typing.get_protocol_members(tp)¶
Retorna o conjunto de membros definidos em um
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
Levanta
TypeError
para argumentos que não são protocolos.Adicionado na versão 3.13.
- typing.is_protocol(tp)¶
Determina se um tipo é um
Protocol
.Por exemplo:
class P(Protocol): def a(self) -> str: ... b: int is_protocol(P) # => True is_protocol(int) # => False
Adicionado na versão 3.13.
- typing.is_typeddict(tp)¶
Verifica se um tipo é um
TypedDict
.Por exemplo:
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)
Adicionado na versão 3.10.
- class typing.ForwardRef¶
Class used for internal typing representation of string forward references.
For example,
List["SomeClass"]
is implicitly transformed intoList[ForwardRef("SomeClass")]
.ForwardRef
should not be instantiated by a user, but may be used by introspection tools.Nota
Tipos genéricos da PEP 585 como
list["SomeClass"]
não serão transformados implicitamente emlist[ForwardRef("SomeClass")]
e, portanto, não serão resolvidos automaticamente paralist[SomeClass]
.Adicionado na versão 3.7.4.
- typing.NoDefault¶
Um objeto sinalizador usado para indicar que um parâmetro de tipo não possui valor-padrão. Por exemplo:
>>> T = TypeVar("T") >>> T.__default__ is typing.NoDefault True >>> S = TypeVar("S", default=None) >>> S.__default__ is None True
Adicionado na versão 3.13.
Constante¶
- typing.TYPE_CHECKING¶
Uma constante especial presumida ser
True
por verificadores de tipo estático de terceiros. ÉFalse
em tempo de execução.Uso:
if TYPE_CHECKING: import expensive_mod def fun(arg: 'expensive_mod.SomeType') -> None: local_var: expensive_mod.AnotherType = other_fun()
A primeira anotação de tipo deve ser colocada entre aspas, tornando-a uma “referência ao futuro”, para esconder do interpretador a referência ao módulo
expensive_mod
. As anotações de tipos em variáveis locais não são avaliadas, então a segunda anotação não precisa ser colocada entre aspas.Nota
Se
from __future__ import annotations
for usado, anotações não serão avaliadas no momento de definição de funções. Em vez disso, elas são armazenadas como string em__annotations__
. Isso torna desnecessário o uso de aspas em anotações (consulte PEP 563).Adicionado na versão 3.5.2.
Apelidos descontinuados¶
Este módulo define vários apelidos descontinuados de classes pré-existentes de classes da biblioteca padrão. Originalmente, elas eram incluídas no módulo typing para permitir a parametrização dessas classes genéricas usand []
. Porém, os apelidos se tornaram redundantes no Python 3.9, quando as classes pré-existentes correspondentes passaram a dar suporte a []
(veja PEP 585).
Os tipos redundantes estão descontinuados desde Python 3.9. No entanto, enquanto os apelidos podem ser removidos em algum momento, essa remoção desses apelidos não está planejada. Assim, nenhum aviso de descontinuação será enviado pelo interpretador para esses apelidos.
Se em algum momento decidirem remover esses apelidos descontinuados, um aviso de descontinuação será enviado pelo interpretador por, no mínimo, duas versões de lançamento antes da remoção. Os apelidos são garantidos a permanecerem no módulo typing sem avisos de descontinuação até, no mínimo, Python 3.14.
Verificadores de tipos são encorajados a sinalizar o uso de tipos descontinuados se o programa que estão verificando respeita uma versão mínima de Python 3.9 ou mais nova.
Apelidos de tipos embutidos¶
- class typing.Dict(dict, MutableMapping[KT, VT])¶
Apelido descontinuado de
dict
.Note que, para anotar argumentos, prefere-se usar um tipo de coleção abstrata como
Mapping
em vez dedict
outyping.Dict
.Obsoleto desde a versão 3.9:
builtins.dict
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- class typing.List(list, MutableSequence[T])¶
Apelido descontinuado de
list
.Note que, para anotar argumentos, é preferível usar um tipo de coleção abstrata, como
Sequence
ouIterable
, em vez delist
outyping.List
.Obsoleto desde a versão 3.9:
builtins.list
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- class typing.Set(set, MutableSet[T])¶
Apelido descontinuado de
builtins.set
.Note que, para anotar argumentos, prefere-se usar um tipo de coleção abstrata como
collections.abc.Set
em vez deset
outyping.Set
.Obsoleto desde a versão 3.9:
builtins.set
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- class typing.FrozenSet(frozenset, AbstractSet[T_co])¶
Apelido descontinuado de
builtins.frozenset
.Obsoleto desde a versão 3.9:
builtins.frozenset
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- typing.Tuple¶
Apelido descontinuado para
tuple
.tuple
eTuple
são casos especiais no sistema de tipos; consulte Anotando tuplas para obter mais detalhes.Obsoleto desde a versão 3.9:
builtins.tuple
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- class typing.Type(Generic[CT_co])¶
Apelido descontinuado de
type
.Consulte O tipo de objetos de classe para obter detalhes sobre como usar
type
outyping.Type
em anotações de tipos.Adicionado na versão 3.5.2.
Obsoleto desde a versão 3.9:
builtins.type
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
Apelidos para tipos em collections
¶
- class typing.DefaultDict(collections.defaultdict, MutableMapping[KT, VT])¶
Apelido descontinuado de
collections.defaultdict
.Adicionado na versão 3.5.2.
Obsoleto desde a versão 3.9:
collections.defaultdict
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- class typing.OrderedDict(collections.OrderedDict, MutableMapping[KT, VT])¶
Apelido descontinuado de
collections.OrderedDict
.Adicionado na versão 3.7.2.
Obsoleto desde a versão 3.9:
collections.OrderedDict
agora oferece suporte a subscrição ([]
). consulte PEP 585 e Tipo Generic Alias.
- class typing.ChainMap(collections.ChainMap, MutableMapping[KT, VT])¶
Apelido descontinuado de
collections.ChainMap
.Adicionado na versão 3.6.1.
Obsoleto desde a versão 3.9:
collections.ChainMap
agora oferece suporte a subscrição ([]
). consulte PEP 585 e Tipo Generic Alias.
- class typing.Counter(collections.Counter, Dict[T, int])¶
Apelido descontinuado de
collections.Counter
.Adicionado na versão 3.6.1.
Obsoleto desde a versão 3.9:
collections.Counter
agora oferece suporte a subscrição ([]
). consulte PEP 585 e Tipo Generic Alias.
- class typing.Deque(deque, MutableSequence[T])¶
Apelido descontinuado de
collections.deque
.Adicionado na versão 3.6.1.
Obsoleto desde a versão 3.9:
collections.deque
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
Apelidos de outros tipos concretos¶
- class typing.Pattern¶
- class typing.Match¶
Apelidos descontinuados correspondem aos tipos de retorno de
re.compile()
ere.match()
.Esses tipos (e as funções correspondentes) são genéricas sobre
AnyStr
.Pattern
pode ser especializado comoPattern[str]
ouPattern[bytes]
;Match
pode ser especializado comoMatch[str]
ouMatch[bytes]
.Obsoleto desde a versão 3.9: Classes
Pattern
eMatch
dere
agora suporte[]
. Consulte PEP 585 e Tipo Generic Alias.
- class typing.Text¶
Apelido descontinuado de
str
.Text
is provided to supply a forward compatible path for Python 2 code: in Python 2,Text
is an alias forunicode
.Use
Text
para indicar que um valor deve conter uma string unicode de forma compatível com Python 2 e Python 3:def add_unicode_checkmark(text: Text) -> Text: return text + u' \u2713'
Adicionado na versão 3.5.2.
Obsoleto desde a versão 3.11: Python 2 deixou de receber suporte, e a maioria dos verificadores de tipos também não oferece suporte à verificação de tipos de código de Python 2. A remoção do apelido não está planejada no momento, mas os usuários são incentivados a usar
str
em vez deText
.
Apelidos de contêineres ABC em collections.abc
.¶
- class typing.AbstractSet(Collection[T_co])¶
Apelido descontinuado de
collections.abc.Set
.Obsoleto desde a versão 3.9:
collections.abc.Set
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- class typing.ByteString(Sequence[int])¶
Este tipo representa os tipos
bytes
,bytearray
ememoryview
de sequências de bytes.Deprecated since version 3.9, will be removed in version 3.14: Prefira
collections.abc.Buffer
, ou uma união comobytes | bytearray | memoryview
.
- class typing.Collection(Sized, Iterable[T_co], Container[T_co])¶
Apelido descontinuado de
collections.abc.Collection
.Adicionado na versão 3.6.
Obsoleto desde a versão 3.9:
collections.abc.Collection
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- class typing.Container(Generic[T_co])¶
Apelido descontinuado de
collections.abc.Container
.Obsoleto desde a versão 3.9:
collections.abc.Container
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- class typing.ItemsView(MappingView, AbstractSet[tuple[KT_co, VT_co]])¶
Apelido descontinuado de
collections.abc.ItemsView
.Obsoleto desde a versão 3.9:
collections.abc.ItemsView
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- class typing.KeysView(MappingView, AbstractSet[KT_co])¶
Apelido descontinuado de
collections.abc.KeysView
.Obsoleto desde a versão 3.9:
collections.abc.KeysView
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- class typing.Mapping(Collection[KT], Generic[KT, VT_co])¶
Apelido descontinuado de
collections.abc.Mapping
.Obsoleto desde a versão 3.9:
collections.abc.Mapping
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- class typing.MappingView(Sized)¶
Apelido descontinuado de
collections.abc.MappingView
.Obsoleto desde a versão 3.9:
collections.abc.MappingView
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- class typing.MutableMapping(Mapping[KT, VT])¶
Apelido descontinuado de
collections.abc.MutableMapping
.Obsoleto desde a versão 3.9:
collections.abc.MutableMapping
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- class typing.MutableSequence(Sequence[T])¶
Apelido descontinuado de
collections.abc.MutableSequence
.Obsoleto desde a versão 3.9:
collections.abc.MutableSequence
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- class typing.MutableSet(AbstractSet[T])¶
Apelido descontinuado de
collections.abc.MutableSet
.Obsoleto desde a versão 3.9:
collections.abc.MutableSet
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- class typing.Sequence(Reversible[T_co], Collection[T_co])¶
Apelido descontinuado de
collections.abc.Sequence
.Obsoleto desde a versão 3.9:
collections.abc.Sequence
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- class typing.ValuesView(MappingView, Collection[_VT_co])¶
Apelido descontinuado de
collections.abc.ValuesView
.Obsoleto desde a versão 3.9:
collections.abc.ValuesView
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
Apelidos para ABCs assíncronas em collections.abc
¶
- class typing.Coroutine(Awaitable[ReturnType], Generic[YieldType, SendType, ReturnType])¶
Apelido descontinuado de
collections.abc.Coroutine
.Consulte Anotando geradores e corrotinas para obter detalhes sobre como usar
collections.abc.Coroutine
etyping.Coroutine
em anotações de tipos.Adicionado na versão 3.5.3.
Obsoleto desde a versão 3.9:
collections.abc.Coroutine
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- class typing.AsyncGenerator(AsyncIterator[YieldType], Generic[YieldType, SendType])¶
Apelido descontinuado de
collections.abc.AsyncGenerator
.Consulte Anotando geradores e corrotinas para obter detalhes sobre como usar
collections.abc.AsyncGenerator
etyping.AsyncGenerator
em anotações de tipos.Adicionado na versão 3.6.1.
Obsoleto desde a versão 3.9:
collections.abc.AsyncGenerator
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.Alterado na versão 3.13: O parâmetro
SendType
agora tem um valor-padrão.
- class typing.AsyncIterable(Generic[T_co])¶
Apelido descontinuado de
collections.abc.AsyncIterable
.Adicionado na versão 3.5.2.
Obsoleto desde a versão 3.9:
collections.abc.AsyncIterable
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- class typing.AsyncIterator(AsyncIterable[T_co])¶
Apelido descontinuado de
collections.abc.AsyncIterator
.Adicionado na versão 3.5.2.
Obsoleto desde a versão 3.9:
collections.abc.AsyncIterator
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- class typing.Awaitable(Generic[T_co])¶
Apelido descontinuado de
collections.abc.Awaitable
.Adicionado na versão 3.5.2.
Obsoleto desde a versão 3.9:
collections.abc.Awaitable
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
Apelidos para outros ABCs em collections.abc
.¶
- class typing.Iterable(Generic[T_co])¶
Apelido descontinuado de
collections.abc.Iterable
.Obsoleto desde a versão 3.9:
collections.abc.Iterable
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- class typing.Iterator(Iterable[T_co])¶
Apelido descontinuado de
collections.abc.Iterator
.Obsoleto desde a versão 3.9:
collections.abc.Iterator
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- typing.Callable¶
Apelido descontinuado de
collections.abc.Callable
.Veja Anotações de objetos chamáveis para detalhes sobre como usar
collections.abc.Callable
etyping.Callable
em anotações de tipo.Obsoleto desde a versão 3.9:
collections.abc.Callable
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.Alterado na versão 3.10:
Callable
agora oferece suporte aParamSpec
eConcatenate
. Veja PEP 612 para mais detalhes.
- class typing.Generator(Iterator[YieldType], Generic[YieldType, SendType, ReturnType])¶
Apelido descontinuado de
collections.abc.Generator
.Consulte Anotando geradores e corrotinas para obter detalhes sobre como usar
collections.abc.Generator
etyping.Generator
em anotações de tipos.Obsoleto desde a versão 3.9:
collections.abc.Generator
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.Alterado na versão 3.13: Adiciona valores-padrão para os tipos de envio e retorno.
- class typing.Hashable¶
Apelido descontinuado de
collections.abc.Hashable
.Obsoleto desde a versão 3.12: Use
collections.abc.Hashable
diretamente.
- class typing.Reversible(Iterable[T_co])¶
Apelido descontinuado de
collections.abc.Reversible
.Obsoleto desde a versão 3.9:
collections.abc.Reversible
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.
- class typing.Sized¶
Apelido descontinuado de
collections.abc.Sized
.Obsoleto desde a versão 3.12: Use
collections.abc.Sized
diretamente.
Apelidos de ABCs da contextlib
¶
- class typing.ContextManager(Generic[T_co, ExitT_co])¶
Apelido descontinuado de
contextlib.AbstractContextManager
.O primeiro parâmetro de tipo,
T_co
, representa o tipo retornado pelo método__enter__()
. O segundo parâmetro opcional de tipo,ExitT_co
, cujo valor-padrão ébool | None
, representa o tipo retornado pelo método__exit__()
.Adicionado na versão 3.5.4.
Obsoleto desde a versão 3.9:
contextlib.AbstractContextManager
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.Alterado na versão 3.13: Adiciona o segundo parâmetro opcional de tipo,
ExitT_co
.
- class typing.AsyncContextManager(Generic[T_co, AExitT_co])¶
Apelido descontinuado de
contextlib.AbstractAsyncContextManager
.O primeiro parâmetro de tipo,
T_co
, representa o tipo retornado pelo método__aenter__()
. O segundo parâmetro opcional de tipo,AExitT_co
, cujo valor-padrão ébool | None
, representa o tipo retornado pelo método__aexit__()
.Adicionado na versão 3.6.2.
Obsoleto desde a versão 3.9:
contextlib.AbstractAsyncContextManager
agora oferece suporte a subscrição ([]
). Consulte PEP 585 e Tipo Generic Alias.Alterado na versão 3.13: Adiciona o segundo parâmetro opcional de tipo,
AExitT_co
.
Cronograma de descontinuação dos principais recursos¶
Alguns recursos em typing
estão descontinuados e podem ser removidos em uma versão futura de Python. A tabela a seguir resume as principais descontinuações para sua conveniência. Ela está sujeita a alterações, e nem todas as descontinuações estão listadas.
Recurso |
Descontinuado em |
Remoção planejada |
PEP/issue |
---|---|---|---|
versões |
3.9 |
Não definido (consulte apelidos descontinuados para mais informações) |
|
3.9 |
3.14 |
||
3.11 |
Não definido |
||
3.12 |
Não definido |
||
3.12 |
Não definido |
||
3.13 |
3.15 |
||
3.13 |
3.18 |