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"A área superficial de um cubo é {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 manter retrocompatibilidade, apelidos de tipo também podem ser criados usando 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 tipo descontinuado typing.Callable
. 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êineres na biblioteca padrão permitem usar subscrição para denotar o tipo esperado dos elementos dos contêineres.
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') # Declara tipo variável "U"
def second(l: Sequence[U]) -> U: # Função é genérica sobre a 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á inferir 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 manter retrocompatibilidade, os apelidos de tipos genéricos também podem ser criados usando 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¶
-
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.A responsabilidade de como interpretar os metadados é da ferramenta ou da biblioteca que encontrar uma anotação
Annotated
. Uma ferramenta ou biblioteca que encontrar um tipoAnnotated
poderá examinar os elementos de metadados para determinar se eles são de interesse (por exemplo, usandoisinstance()
).- Annotated[<type>, <metadata>]
Aqui está um exemplo de como você pode usar
Annotated
para adicionar metadados a anotações de tipos se estiver fazendo uma análise de intervalos:@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")]
Cabe à ferramenta que consome as anotações decidir se o cliente tem permissão de adicionar vários elementos de metadados a uma anotação e como mesclar essas anotações.
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)] # Quando usado em uma anotação de tipo, um verificador de tipos tratará "V" da mesma forma que # ``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
pode ser usado para anotar o tipo de retorno de uma função de predicado de tipo definida pelo usuário.TypeIs
aceita apenas um único argumento de tipo. Em tempo de execução, funções marcadas dessa forma devem retornar um booleano e receber, no mínimo, um argumento posicional.TypeIs
visa beneficiar estreitamento de tipo – uma técnica usada por verificador de tipo estático para determinar um tipo mais preciso de expressão dentro do fluxo de código de um programa. Normalmente, o estreitamento de tipo é feito por meio da análise do fluxo de código condicional e da aplicação do estreitamento a um bloquear código. A condicional expressão aqui é às vezes chamada de “predicado de tipo”:def is_str(val: str | float): # predicado de tipos "isinstance" if isinstance(val, str): # Tipo de ``val`` é restrito a ``str`` ... else: # Senão, tipo de ``val`` é restrito a ``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)
O tipo dentro de
TypeIs
deve ser consistente com o tipo do argumento da função; caso contrário, o verificador de tipo estático levantará um erro. Uma funçãoTypeIs
escrita incorretamente pode ocasionar um comportamento insensato pelo sistema de tipos; é de responsabilidade do usuário escrever tais funções de forma segura para tipos.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
também funciona com tipos variáveis. Consulte a PEP 647 para obter mais detalhes.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.
Por exemplo, usar o operador de desempacotamento
*
em uma tupla de tipos variáveis equivale a usar oUnpack
para marcar a tupla de tipos variáveis como tendo sido desempacotada: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¶
As classes a seguir não devem ser usadas diretamente como anotações. propósito O objetivo delas é construir bloquear para criar genérico e digitar apelido.
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.
Para manter retrocompatibilidade, as classes genéricas também podem ser declaradas herdando explicitamente de
Generic
. Nesse caso, os parâmetros de tipo devem ser declarados separadamente: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 ...
Essa sintaxe também pode ser usada para criar tipos variáveis delimitados e tipos variáveis restritos:
class StrSequence[S: str]: # S é uma TypeVar delimitada a str ... class StrOrBytesSequence[A: (str, bytes)]: # A é uma TypeVar restrita a str ou 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]: """Retorna uma lista contendo n referências para x.""" return [x]*n def print_capitalized[S: str](x: S) -> S: """Exibe x capitalizado, e retorna x.""" print(x.capitalize()) return x def concatenate[A: (str, bytes)](x: A, y: A) -> A: """Concatena dois objetos string ou bytes.""" return x + y
Observe que tipos variáveis podem ser delimitados, restritos, nenhum dos dois, mas não podem ser ambos.
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.Tipos variáveis delimitados e tipos variáveis restritos têm semânticas diferentes de várias formas importantes. Usar um tipo variável delimitado significa que a
TypeVar
será resolvido usando o tipo mais específico possível:x = print_capitalized('a string') reveal_type(x) # tipo revelado é str class StringSubclass(str): pass y = print_capitalized(StringSubclass('another string')) reveal_type(y) # tipo revelado é StringSubclass z = print_capitalized(45) # erro: int não é subtipo de str
Type variables can be bound to concrete types, abstract types (ABCs or protocols), and even unions of types:
# Pode ser qualquer coisa com um método __abs__ def print_abs[T: SupportsAbs](arg: T) -> None: print("Absolute value:", abs(arg)) U = TypeVar('U', bound=str|bytes) # Pode ser qualquer subtipo com a união str | bytes V = TypeVar('V', bound=SupportsAbs) # Pode ser qualquer coisa com um método __abs__
Porém, usar um tipo variável restrito significa que a
TypeVar
só poderá ser resolvida como sendo exatamente uma das restrições dadas:a = concatenate('one', 'two') reveal_type(a) # revealed type is str b = concatenate(StringSubclass('one'), StringSubclass('two')) reveal_type(b) # revealed type is str, despite StringSubclass being passed in c = concatenate('one', b'two') # error: type variable 'A' can be either str or bytes in a function call, but not both
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).
- evaluate_bound()¶
An evaluate function corresponding to the
__bound__
attribute. When called directly, this method supports only theVALUE
format, which is equivalent to accessing the__bound__
attribute directly, but the method object can be passed toannotationlib.call_evaluate_function()
to evaluate the value in a different format.Adicionado na versão 3.14.
- __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).
- evaluate_constraints()¶
An evaluate function corresponding to the
__constraints__
attribute. When called directly, this method supports only theVALUE
format, which is equivalent to accessing the__constraints__
attribute directly, but the method object can be passed toannotationlib.call_evaluate_function()
to evaluate the value in a different format.Adicionado na versão 3.14.
- __default__¶
The default value of the type variable, or
typing.NoDefault
if it has no default.Adicionado na versão 3.13.
- evaluate_default()¶
An evaluate function corresponding to the
__default__
attribute. When called directly, this method supports only theVALUE
format, which is equivalent to accessing the__default__
attribute directly, but the method object can be passed toannotationlib.call_evaluate_function()
to evaluate the value in a different format.Adicionado na versão 3.14.
- 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=())
Observe o uso do operador de desempacotamento
*
emtuple[T, *Ts]
. Conceitualmente, você pode interpretarTs
como uma tupla de tipos variáveis(T1, T2, ...)
. Então o tipotuple[T, *Ts]
se tornariatuple[T, *(T1, T2, ...)]
, que equivale atuple[T, T1, T2, ...]
. (Note que, em versões mais antigas de Python, você pode encontrar isso escrito comUnpack
em vez deUnpack[Ts]
.)Tuplas de tipos variáveis devem sempre ser desempacotadas. Isso ajuda a distinguir entre tuplas de tipos variáveis e tipos variáveis normais:
x: Ts # Inválido x: tuple[Ts] # Inválido x: tuple[*Ts] # O jeito correto
As tuplas de tipos variáveis podem ser usadas no mesmo contexto que tipos variáveis normais. Por exemplo, em argumentos, tipos de retorno e definições de classes:
class Array[*Shape]: def __getitem__(self, key: tuple[*Shape]) -> float: ... def __abs__(self) -> "Array[*Shape]": ... def get_shape(self) -> tuple[*Shape]: ...
As tuplas de tipos variáveis podem ser combinadas com tipos variáveis normais:
class Array[DType, *Shape]: # Tudo certo aqui pass class Array2[*Shape, DType]: # Tudo certo aqui também pass class Height: ... class Width: ... float_array_1d: Array[float, Height] = Array() # Totalmente certo int_array_2d: Array[int, Height, Width] = Array() # Sim, certo também
No entanto, observe que no máximo uma tupla de tipos variáveis pode aparecer em uma única lista de argumentos de tipo ou parâmetros de tipo:
x: tuple[*Ts, *Ts] # Inválido class Array[*Shape, *Shape]: # Inválido pass
Por fim, uma tupla de tipos variáveis desempacotada pode ser usada como anotação de tipo de
*args
:def call_soon[*Ts]( callback: Callable[[*Ts], None], *args: *Ts ) -> None: ... callback(*args)
Ao contrário do que acontece com anotações não desempacotadas de
*args
- por exemplo,*args: int
, que especificaria que todos os argumentos sãoint
-,*args: *Ts
permite referenciar os tipos de cada argumento em*args
individualmente. Isso nos permite garantir que os tipos em*args
passados paracall_soon
correspondem aos tipos dos argumentos (posicionais) decallback
.Consulte a PEP 646 para mais detalhes sobre tuplas de tipos variáveis.
- __name__¶
O nome da tupla de tipos variáveis.
- __default__¶
O valor padrão da tupla de tipos variáveis, ou
typing.NoDefault
se não existir padrão.Adicionado na versão 3.13.
- evaluate_default()¶
An evaluate function corresponding to the
__default__
attribute. When called directly, this method supports only theVALUE
format, which is equivalent to accessing the__default__
attribute directly, but the method object can be passed toannotationlib.call_evaluate_function()
to evaluate the value in a different format.Adicionado na versão 3.14.
- has_default()¶
Retorna se a tupla de tipos variáveis tem ou não um valor padrão. Isso equivale a verificar se
__default__
não é o singletontyping.NoDefault
, exceto por não forçar a avaliação instantânea do valor padrão que é avaliado preguiçosamente.Adicionado na versão 3.13.
Adicionado na versão 3.11.
Alterado na versão 3.12: Tuplas de tipos variáveis 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.
- class typing.ParamSpec(name, *, bound=None, covariant=False, contravariant=False, default=typing.NoDefault)¶
Variável de especificação de parâmetro. Uma versão especializada de tipos variáveis.
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')
Variáveis de especificação de parâmetro existem principalmente para o benefício de verificadores de tipo estático. São usadas para encaminhar os tipos de parâmetros de um chamável para outro chamável – um padrão comumente encontrado em funções e decoradores de ordem superior. Só são válidas quando usados em
Concatenate
, ou como o primeiro argumento paraCallable
, ou como parâmetro para genéricos definidos pelo usuário. ConsulteGeneric
para obter mais informações sobre tipos genéricos.Por exemplo, para adicionar um registro básico de eventos a uma função, é possível criar um decorador
add_logging
para registrar chamadas de função. A variável de especificação de parâmetro informa ao verificador de tipos que o chamável passado para o decorador e o novo chamável retornado por ele têm parâmetros de tipo interdependentes:from collections.abc import Callable import logging def add_logging[T, **P](f: Callable[P, T]) -> Callable[P, T]: '''Um decorador com segurança de tipos que acrescenta registros de eventos (logs) a uma função.''' 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: '''Soma dois números.''' 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()
pode ser exigida no corpo do decoradoradd_logging
ao retornar a funçãoinner
, ou o verificador de tipo estático deverá ser instruído a ignorar oreturn 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.
- evaluate_default()¶
An evaluate function corresponding to the
__default__
attribute. When called directly, this method supports only theVALUE
format, which is equivalent to accessing the__default__
attribute directly, but the method object can be passed toannotationlib.call_evaluate_function()
to evaluate the value in a different format.Adicionado na versão 3.14.
- has_default()¶
Retorna se a especificação de parâmetros tem ou não um valor padrão. Isso equivale a verificar se
__default__
não é o singletontyping.NoDefault
, exceto pelo fato de que a função não força a avaliação instantânea do valor padrão em vez de usar avaliação preguiçosa.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¶
Tipos dos argumentos e dos argumentos nomeados de um
ParamSpec
. O atributoP.args
de umParamSpec
é uma instância deParamSpecArgs
, e o atributoP.kwargs
é uma instância deParamSpecKwargs
. São destinados à introspecção em tempo de execução, e não têm nenhum significado especial para o verificador de tipo estático.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__¶
O valor do apelido de tipo. Isso é uma avaliação preguiçosa, portanto, os nomes usados na definição do apelido não são resolvidos até que o atributo
__value__
seja acessado:>>> type Mutually = Recursive >>> type Recursive = Mutually >>> Mutually Mutually >>> Recursive Recursive >>> Mutually.__value__ Recursive >>> Recursive.__value__ Mutually
- evaluate_value()¶
An evaluate function corresponding to the
__value__
attribute. When called directly, this method supports only theVALUE
format, which is equivalent to accessing the__value__
attribute directly, but the method object can be passed toannotationlib.call_evaluate_function()
to evaluate the value in a different format:>>> type Alias = undefined >>> Alias.__value__ Traceback (most recent call last): ... NameError: name 'undefined' is not defined >>> from annotationlib import Format, call_evaluate_function >>> Alias.evaluate_value(Format.VALUE) Traceback (most recent call last): ... NameError: name 'undefined' is not defined >>> call_evaluate_function(Alias.evaluate_value, Format.FORWARDREF) ForwardRef('undefined')
Adicionado na versão 3.14.
Outras diretivas especiais¶
Essas funções e classes não devem ser usadas diretamente como anotações. O objetivo é que sejam blocos de construção para criar e declarar tipos.
- class typing.NamedTuple¶
Versão tipada de
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.
A classe resultante tem um atributo extra
__annotations__
que fornece um dicionário que mapeia os nomes de campos para os tipos de campos. (Os nomes de campos estão no atributo_fields
e os valores padrão estão no atributo_field_defaults
, e ambos fazem parte da API denamedtuple()
.)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]
Uso retrocompatível:
# Para criar um NamedTuple genérico em Python 3.11 T = TypeVar("T") class Group(NamedTuple, Generic[T]): key: T group: list[T] # Também há suporte para a sintaxe funcional 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: Ao usar o funcional sintaxe para criar uma classe NamedTuple, a falha ao passar um valor para o ‘campo’ parâmetro (
NT = NamedTuple("NT")
) é descontinuado. PassarNone
para o ‘campo’ parâmetro (NT = NamedTuple("NT", None)
) também é descontinuado. Ambos não serão permitidos em Python 3.15. Para criar uma classe NamedTuple com 0 campo, useclass NT(NamedTuple): pass
ouNT = 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, chamarNewType
retorna seu argumento inalterado.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
Consulte a PEP 544 para obter mais detalhes. Classes de protocolo decoradas com
runtime_checkable()
(descritas posteriormente) funcionam como protocolos em tempo de execução simples, somente verificando a presença de determinados atributos, e ignorando suas assinaturas de tipo.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()
verificará apenas a presença dos métodos ou atributos obrigatórios, em vez de tipos ou assinaturas de tipos. Por exemplo, ossl.SSLObject
é uma classe e, portanto, passa por uma verificaçãoissubclass()
em relação ao Callable. No entanto, o métodossl.SSLObject.__init__
existe apenas para levantar umTypeError
com uma mensagem mais informativa, o que impossibilita chamar (instanciar) ossl.SSLObject
.Nota
A verificação
isinstance()
sobre um protocolo verificável em tempo de execução pode ser surpreendentemente lenta se comparada a uma verificaçãoisinstance()
sobre outros tipos de classe. Considere usar expressões alternativas, como chamar a funçãohasattr()
para realizar verificações estruturais em código sensível a desempenho.Adicionado na versão 3.8.
Alterado na versão 3.12: O implementação interno do
isinstance()
verifica os protocolos verificáveis do tempo de execução agora usa oinspect.getattr_static()
para procurar o atributo (anteriormente, era usado ohasattr()
). Como resultado, alguns objetos que costumavam ser considerados instâncias de um tempo de execução-checkable protocolo podem não ser mais considerados instâncias desse protocolo em Python 3.12+, e vice-versa. É improvável que a maioria dos usuários seja afetada por essa alteração.Alterado na versão 3.12: Os membros de um protocolo verificável em tempo de execução agora serão considerados “congelados” em tempo de execução assim que a classe for criada. A alteração dinâmica de atributos de um protocolo em tempo de execução ainda funcionará, mas não terá impacto nas verificações
isinstance()
ao comparar objetos com o protocolo. Consulte typing para obter mais detalhes.
- 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
declara um tipo dicionário que espera que todas as suas instâncias tenham um determinado conjunto de chaves, onde cada chave está associada a um valor de um tipo consistente. Essa expectativa não é verificada em tempo de execução, mas é imposta apenas por verificadores de tipos. Modo de usar: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__
.Para manter a retrocompatibilidade com Python 3.10 e versões anteriores, também é possível usar herança para declarar chaves obrigatórias e opcionais no mesmo
TypedDict
. Isso é feito declarando umTypedDict
com um valor para o argumentototal
e então herdando-a em outroTypedDict
usando um valortotal
diferente:>>> 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: Ao usar o funcional sintaxe para criar uma classe TypedDict, a falha ao passar um valor para o ‘campo’ parâmetro (
TD = TypedDict("TD")
) é descontinuado. PassarNone
para o ‘campo’ parâmetro (TD = TypedDict("TD", None)
) também é descontinuado. Ambos não serão permitidos em Python 3.15. Para criar uma classe TypedDict com 0 campo, useclass TD(TypedDict): pass
ouTD = 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.
Isso retorna o valor inalterado. Para o verificador de tipos, isso indica que o valor de retorno tem o tipo designado, mas em tempo de execução não verificamos nada intencionalmente (queremos que isso seja o mais rápido possível).
- typing.assert_type(val, typ, /)¶
Pede para um verificador de tipo estático confirmar se val tem tipo inferido typ.
Essa função faz nada em tempo de execução: ela retorna o primeiro argumento inalterado, sem verificações ou efeitos colaterais, independentemente do tipo real do argumento.
Quando um verificador de tipo estático encontra uma chamada para
assert_type()
, ele emite um erro se o valor não for do tipo especificado: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): # Realiza alguma lógica complexa de restrição de tipos # após a qual esperamos que o tipo seja `int` ... # Testa se o verificador de tipos entendeu nossa função corretamente 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)
Aqui, as anotações permitem que o verificador de tipos deduza que o último caso nunca será executado, pois
arg
é umint
ou umastr
, e ambas as opções são cobertas por casos anteriores.Se um verificador de tipos descobrir que uma chamada para
assert_never()
é alcançável, ele emitirá um erro. por exemplo, se o anotação de tipo paraarg
fosseint | str | float
, o verificador de tipos emitiria um erro indicando queunreachable
é do tipofloat
. Para que uma chamada paraassert_never
passe verificação de tipos, o tipo inferido do argumento passado deve ser o tipo inferior,Never
, e nada mais.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.
Quando um verificador de tipo estático encontra uma chamada para essa função, ele emite um diagnóstico com o tipo inferido do argumento. Por exemplo:
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.
Em tempo de execução, esta função envia o tipo de seu argumento para
sys.stderr
e retorna o argumento inalterado (permitindo que a chamada seja usada em uma expressão):x = reveal_type(1) # exibe "Runtime type is int" print(x) # exibe "1"
Observe que o tipo em tempo de execução pode ser diferente (mais ou menos específico) do tipo inferido estaticamente por um verificador de tipos.
A maioria dos verificadores de tipos dá suporte a
reveal_type()
em qualquer lugar, mesmo que o nome não seja importado detyping
. Porém, importar o nome detyping
permite que o código seja executado sem erros em tempo de execução e comunica a intenção com mais clareza.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
pode ser usado para decorar uma classe, metaclasse, ou função decoradora. A presença de@dataclass_transform()
informa a um verificador de tipo estático que o objeto decorado executa “mágica” em tempo de execução que transforma uma classe de maneira semelhante a@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
As classes
CustomerModel
definidas acima serão tratadas pelos verificadores de tipos semelhantemente às classes criadas com@dataclasses.dataclass
. Por exemplo, os verificadores de tipo presumirão que essas classes têm métodos__init__
que aceitamid
ename
.A classe, metaclasse, ou função decorada pode aceitar os seguintes argumentos booleanos tal que verificadores de tipo presumirão ter o mesmo efeito que teriam no decorador
@dataclasses.dataclass
:init
,eq
,order
,unsafe_hash
,frozen
,match_args
,kw_only
, eslots
. É necessário que o valor desses argumentos (True
ouFalse
) seja avaliado estaticamente.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) – Indica se o parâmetro
eq
é presumido comoTrue
ouFalse
se for omitido pelo chamador. O padrão éTrue
.order_default (bool) – Indica se o parâmetro
order
é presumido comoTrue
ouFalse
se for omitido pelo chamador. O padrão éFalse
.kw_only_default (bool) – Indica se o parâmetro
kw_only
é presumido comoTrue
ouFalse
se for omitido pelo chamador. O padrão éFalse
.frozen_default (bool) – Indica se o parâmetro
frozen
é presumido comoTrue
ouFalse
se for omitido pelo chamador. O padrão éFalse
. .. versionadded:: 3.12field_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:
¶ 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
Fornece uma função de retorno de tempo de execução que retorna o valor padrão do campo. Se nem
default
nemdefault_factory
forem especificados, o campo é presumido como sem valor padrão e deverá receber um valor quando a classe for instanciada.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.Em tempo de execução, esse decorador registra seu argumento no atributo
__dataclass_transform__
no objeto decorado. Ele não tem nenhum outro efeito em tempo de execução.Consulte PEP 681 para mais detalhes.
Adicionado na versão 3.11.
- @typing.overload¶
Decorador para criar funções e métodos sobrecarregados.
O decorador
@overload
permite descrever funções e métodos com suporte a várias combinações de tipos de argumento. Uma sequência de definições decoradas com@overload
deve preceder uma única definição não decorada por@overload
(para a mesma função/método).Definições decoradas com
@overload
são usadas somente para benefício do verificador de tipos, já que serão sobrescritas por definições sem decoração de@overload
. Enquanto isso, definições sem decoração de@overload
serão usadas em tempo de execução, mas devem ser ignoradas pelo verificador de tipos. Em tempo de execução, chamar uma função decorada por@overload
diretamente levantaráNotImplementedError
.Um exemplo de sobrecarga que fornece um tipo mais preciso do que o tipo expresso usando uma união ou um tipo variável:
@overload def process(response: None) -> None: ... @overload def process(response: int) -> tuple[int, str]: ... @overload def process(response: bytes) -> str: ... def process(response): ... # a implementação real vem aqui
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.
Decorar um método com
@final
indica a um verificador de tipos que o método não pode ser substituído em uma subclasse. Decorar uma classe com@final
indica que ela não pode ser herdada.Por exemplo:
class Base: @final def done(self) -> None: ... class Sub(Base): def done(self) -> None: # Erro reportado pelo verificador de tipos ... @final class Leaf: ... class Other(Leaf): # Erro 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.
Alterado na versão 3.11: O decorador tentará definir um atributo
__final__
comoTrue
no objeto decorado. Assim, uma verificação comoif getattr(obj, "__final__", False)
pode ser usada em tempo de execução para determinar se um objetoobj
foi marcado como final. Se o objeto decorado dá suporte a definição de atributos, o decorador retorna o objeto inalterado sem levantar uma exceção.
- @typing.no_type_check¶
Decorador para indicar que anotações não são dicas de tipo.
Isso funciona como decorator de uma classe ou função. Com uma classe, ele se aplica recursivamente a todos os métodos e classes definidos nessa classe (mas não a métodos definidos em suas superclasses ou subclasses). Os verificadores de tipos ignorarão todas as anotações em uma função ou classe com este decorador.
@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 substituir um método ou atributo em uma superclasse.
Os verificadores de tipo devem emitir um erro se um método decorado com
@override
substituir nada. Isso ajuda a evitar erros que podem ocorrer quando uma classe base muda sem uma mudança equivalente em uma classe filha.Por exemplo:
class Base: def log_status(self) -> None: ... class Sub(Base): @override def log_status(self) -> None: # OK: substitui Base.log_status ... @override def done(self) -> None: # Erro reportado pelo verificador de tipos ...
Não há verificação desta propriedade em tempo de execução.
O decorador tentará definir um atributo
__override__
comoTrue
no objeto decorado. Assim, uma verificação comoif getattr(obj, "__override__", False)
poderá ser usada em tempo de execução para determinar se um objetoobj
foi marcado como uma substituição. Se o objeto decorado não der suporte à atribuição de atributos, o decorador retorna o objeto inalterado sem levantar uma exceção.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: # privado ou indisponível em tempo de execução 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.Se obj for uma classe
C
, o função retorno é um dicionário que mescla anotações das classes base doC
com as doC
diretamente. Isso é feito percorrendoC.__mro__
e combinando iterativamente__annotations__
dicionário . anotações em classes que aparecem mais cedo no ordem de resolução de métodos sempre tem precedência sobre anotações em classes que aparecem mais tarde no ordem de resolução de métodos.O função substitui recursivamente todas as ocorrências de
Annotated[T, ...]
porT
, a menos que include_extras seja definido comoTrue
(consulteAnnotated
para obter mais informações).
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: Anteriormente,
Optional[t]
era adicionado a anotações de funções e métodos se um valor padrão igual aNone
fosse definido. Agora, a anotação é retornada inalterada.
- 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, ...)
.Se
X
for uma união ou umLiteral
, e estiver contido em outro tipo genérico, a ordem de(Y, Z, ...)
poderá ser diferente da ordem dos argumentos originais[Y, Z, ...]
devido ao armazenamento dos tipos em cache. Retorna()
para objetos sem suporte.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 é uma fábrica para criar dicionários tipados # e não um dicionário tipado em si. 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.
Alterado na versão 3.14: This is now an alias for
annotationlib.ForwardRef
.
- typing.evaluate_forward_ref(forward_ref, *, owner=None, globals=None, locals=None, type_params=None, format=annotationlib.Format.VALUE)¶
Evaluate an
annotationlib.ForwardRef
as a type hint.This is similar to calling
annotationlib.ForwardRef.evaluate()
, but unlike that method,evaluate_forward_ref()
also:Recursively evaluates forward references nested within the type hint.
Raises
TypeError
when it encounters certain objects that are not valid type hints.Replaces type hints that evaluate to
None
withtypes.NoneType
.Supports the
FORWARDREF
andSTRING
formats.
forward_ref must be an instance of
ForwardRef
. owner, if given, should be the object that holds the annotations that the forward reference derived from, such as a module, class object, or function. It is used to infer the namespaces to use for looking up names. globals and locals can also be explicitly given to provide the global and local namespaces. type_params is a tuple of type parameters that are in scope when evaluating the forward reference. This parameter must be provided (though it may be an empty tuple) if owner is not given and the forward reference does not already have an owner set. format specifies the format of the annotation and is a member of theannotationlib.Format
enum.Adicionado na versão 3.14.
- 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 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 []
(consulte a 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, o interpretador emitirá um aviso de descontinuação 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.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.11 |
Não definido |
||
3.12 |
Não definido |
||
3.12 |
Não definido |
||
3.13 |
3.15 |
||
3.13 |
3.18 |