# `typing` — Suporte para dicas de tipo

Adicionado na versão 3.5.

Código-fonte: Lib/typing.py

Nota

O tempo de execução do Python não força anotações de tipos de variáveis e funções. Elas podem ser usadas por ferramentas de terceiros como verificadores de tipo, IDEs, linters, etc.

Este módulo fornece suporte em tempo de execução para dicas de tipo.

Considere a função abaixo:

    def surface_area_of_cube(edge_length: float) -> str:
        return f"The surface area of the cube is {6 * edge_length ** 2}."

A função `surface_area_of_cube` recebe um argumento que se espera ser uma instância de `float`, conforme indicado pela dica de tipo `edge_length: float`. Espera-se que a função retorne uma instância de `str`, conforme indicado pela dica `-> str`.

Embora as dicas de tipo possam ser classes simples como `float` ou `str`, elas também podem ser mais complexas. O módulo `typing` fornece um vocabulário de dicas de tipo mais avançadas.

Novos recursos são frequentemente adicionados ao módulo `typing`. O pacote typing_extensions fornece backports desses novos recursos para versões mais antigas do Python.

Ver também

“Guia rápido sobre Dicas de Tipo”

  Uma visão geral das dicas de tipo (hospedado por mypy docs, em inglês).

“Referência sobre Sistema de Tipo” seção de the mypy docs

  O sistema de tipagem do Python é padronizado pelas PEPs, portanto esta referência deve se aplicar a maioria do verificadores de tipo do Python. (Alguns trechos podem se referir especificamente ao mypy. Documento em inglês).

“Tipagem Estática com Python”

  Documentação independente de verificador de tipo escrita pela comunidade, detalhando os recursos do sistema de tipo, ferramentas úteis de tipagem e melhores práticas.

## Especificação para o sistema de tipos do Python

A especificação canônica e atualizada do sistema de tipos Python pode ser encontrada em “Specification for the Python type system”.

## Apelidos de tipo

Um apelido de tipo é definido utilizando a instrução `type`, que por sua vez cria uma instância da classe `TypeAliasType`. Neste exemplo, `Vector` e `list[float]` serão tratados de maneira equivalente pelos verificadores de tipo estático:

    type Vector = list[float]

    def scale(scalar: float, vector: Vector) -> Vector:
        return [scalar * num for num in vector]

    # passa na verificação de tipos; uma lista de floats é qualificada como Vector.
    new_vector = scale(2.0, [1.0, -4.2, 5.4])

Apelidos de tipo são úteis para simplificar assinaturas de tipo complexas. Por exemplo:

    from collections.abc import Sequence

    type ConnectionOptions = dict[str, str]
    type Address = tuple[str, int]
    type Server = tuple[Address, ConnectionOptions]

    def broadcast_message(message: str, servers: Sequence[Server]) -> None:
        ...

    # O verificador de tipo tratará a assinatura de tipo anterior
    # como exatamente equivalente à assinatura abaixo.
    def broadcast_message(
        message: str,
        servers: Sequence[tuple[tuple[str, int], dict[str, str]]]
    ) -> None:
        ...

A instrução `type` é nova no Python 3.12. Para compatibilidade retroativa, apelidos de tipo também podem ser criados através da simples atribuição:

    Vector = list[float]

Ou marcado com `TypeAlias` para tornar explícito que se trata de um apelido de tipo e não uma atribuição de variável comum:

    from typing import TypeAlias

    Vector: TypeAlias = list[float]

## NewType

Utilize o auxiliar `NewType` para criar tipos únicos:

    from typing import NewType

    UserId = NewType('UserId', int)
    some_id = UserId(524313)

O verificador de tipo estático tratará o novo tipo como se fosse uma subclasse do tipo original. Isso é útil para ajudar a encontrar erros de lógica:

    def get_user_name(user_id: UserId) -> str:
        ...

    # passa na verificação de tipo
    user_a = get_user_name(UserId(42351))

    # falha na verificação de tipo: um int não é um UserId
    user_b = get_user_name(-1)

Você ainda pode executar todas as operações `int` em uma variável do tipo `UserId`, mas o resultado sempre será do tipo `int`. Isso permite que você passe um `UserId` em qualquer ocasião que `int` possa ser esperado, mas previne que você acidentalmente crie um `UserId` de uma forma inválida:

    # 'output' é do tipo 'int', em vez de 'UserId'
    output = UserId(23413) + UserId(54341)

Note que essas verificações são aplicadas apenas pelo verificador de tipo estático. Em tempo de execução, a instrução `Derived = NewType('Derived', Base)` irá tornar `Derived` um chamável que retornará imediatamente qualquer parâmetro que você passar. Isso significa que a expressão `Derived(some_value)` não cria uma nova classe ou introduz sobrecarga além de uma chamada regular de função.instrução

Mais precisamente, a expressão `some_value is Derived(some_value)` é sempre verdadeira em tempo de execução.

É inválido criar um subtipo de `Derived`:

    from typing import NewType

    UserId = NewType('UserId', int)

    # Falha em tempo de execução e não passa na verificação de tipos
    class AdminUserId(UserId): pass

No entanto, é possível criar um `NewType` baseado em um ‘derivado’ `NewType`:

    from typing import NewType

    UserId = NewType('UserId', int)

    ProUserId = NewType('ProUserId', UserId)

e a verificação de tipos para `ProUserId` funcionará como esperado.

Veja PEP 484 para mais detalhes.

Nota

Lembre-se que o uso de um apelido de tipo declara que dois tipos serão equivalentes entre si. Efetuar `type Alias = Original` fará o verificador de tipo estático tratar `Alias` como sendo exatamente equivalente a `Original` em todos os casos. Isso é útil quando você deseja simplificar assinaturas de tipo complexas.

Em contraste, `NewType` declara que um tipo será subtipo de outro. Efetuando `Derived = NewType('Derived', Original)` irá fazer o verificador de tipo estático tratar `Derived` como uma subclasse de `Original`, o que significa que um valor do tipo `Original` não pode ser utilizado onde um valor do tipo `Derived` é esperado. Isso é útil quando você deseja evitar erros de lógica com custo mínimo de tempo de execução.

Adicionado na versão 3.5.2.

Alterado na versão 3.10: `NewType` agora é uma classe em vez de uma função. Consequentemente, existem alguns custos em tempo de execução ao chamar `NewType` em vez de uma função comum.

Alterado na versão 3.11: O desempenho de chamar `NewType` voltou ao mesmo nível da versão Python 3.9.

## Anotações de objetos chamáveis

Funções – ou outros objetos chamáveis – podem ser anotados com `collections.abc.Callable` ou com o `typing.Callable` descontinuado. `Callable[[int], str]` expressa uma função que recebe um único parâmetro de tipo `int` e retorna uma `str`.

Por exemplo:

    from collections.abc import Callable, Awaitable

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

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

    async def on_update(value: str) -> None:
        ...  # Corpo

    callback: Callable[[str], Awaitable[None]] = on_update

A sintaxe da subscrição deve sempre ser usada com exatamente dois valores: uma lista de argumentos e o tipo de retorno. A lista de argumentos deve ser uma lista de tipos, um `ParamSpec`, `Concatenate`, ou reticências. O tipo de retorno deve ser um único tipo.

Se uma reticências literal `...` é passada no lugar de uma lista de argumentos, ela indica que um chamável com uma lista de qualquer parâmetro arbitrário seria aceita.

    def concat(x: str, y: str) -> str:
        return x + y

    x: Callable[..., str]
    x = str     # OK
    x = concat  # OK também

`Callable` não pode representar assinaturas complexas, como funções que aceitam um número variado de argumentos, funções sobrecarregadas, or funções que recebem apenas parâmetros somente-nomeados. No entanto, essas assinaturas podem ser expressas ao se definir uma `Protocol` com um método `__call__()`:

    from collections.abc import Iterable
    from typing import Protocol

    class Combiner(Protocol):
        def __call__(self, *vals: bytes, maxlen: int | None = None) -> list[bytes]: ...

    def batch_proc(data: Iterable[bytes], cb_results: Combiner) -> bytes:
        for item in data:
            ...

    def good_cb(*vals: bytes, maxlen: int | None = None) -> list[bytes]:
        ...
    def bad_cb(*vals: bytes, maxitems: int | None) -> list[bytes]:
        ...

    batch_proc([], good_cb)  # OK
    batch_proc([], bad_cb)   # Erro! Argumento 2 tem tipo incompatível por ter
                             # nome e tipo diferente do callback

Chamáveis que recebem outros chamáveis como argumentos podem indicar que seus tipos de parâmetro dependem uns dos outros usando `ParamSpec`. Além disso, se esse chamável adiciona ou remove argumentos de outros chamáveis, o operador `Concatenate` pode ser usado. Eles assumem a forma de `Callable[ParamSpecVariable, ReturnType]` e `Callable[Concatenate[Arg1Type, Arg2Type, ..., ParamSpecVariable], ReturnType]`, respectivamente.

Alterado na versão 3.10: `Callable` agora oferece suporte a `ParamSpec` e `Concatenate`. Veja PEP 612 para mais detalhes.

Ver também

A documentação para `ParamSpec` e `Concatenate` contém exemplos de uso em `Callable`.

## Genéricos

Como a informação de tipo sobre objetos mantidos em contêineres não pode ser inferida estaticamente de uma maneira genérica, muitas classes de contêiner na biblioteca padrão permitem subscrição para denotar tipos esperados de elementos de contêiner.

    from collections.abc import Mapping, Sequence

    class Employee: ...

    # Sequence[Employee] indica que todos os elementos na sequência
    # devem ser instâncias de "Employee".
    # Mapping[str, str] indica que todas as chaves e valores no mapeamento
    # devem ser strings.
    def notify_by_email(employees: Sequence[Employee],
                        overrides: Mapping[str, str]) -> None: ...

Funções e classes genéricas podem ser parametrizadas utilizando a sintaxe de parâmetro de tipos:

    from collections.abc import Sequence

    def first[T](l: Sequence[T]) -> T:  # Função é genérica sobre TypeVar "T"
        return l[0]

Ou utilizando a fábrica `TypeVar` diretamente:

    from collections.abc import Sequence
    from typing import TypeVar

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

    def second(l: Sequence[U]) -> U:  # Function is generic over the TypeVar "U"
        return l[1]

Alterado na versão 3.12: O suporte sintático para genéricos é novo no Python 3.12.

## Anotando tuplas

Para a maior parte dos tipos containers em Python, o sistema de tipagem presume que todos os elementos do contêiner são do mesmo tipo. Por exemplo:

    from collections.abc import Mapping

    # Verificador de tipos irá inferor que todos os elementos em ``x`` devem ser ints
    x: list[int] = []

    # Erro no verificador: ``list`` aceita um único tipo de argumento
    y: list[int, str] = [1, 'foo']

    # Verificador de tipos irá inferir que todas as chaves em ``z`` devem ser strings,
    # e todos os valores em ``z`` devem ser strings ou ints
    z: Mapping[str, str | int] = {}

`list` aceita apenas um tipo de argumento, e assim o verificador de tipos emitirá um erro na atribuição `y` acima. Da mesma forma, `Mapping` aceita apenas dois tipos de argumento: O primeiro indica o tipo das chaves, e o segundo indica o tipo dos valores.

Ao contrário da maioria dos outros contêineres Python, é comum no código Python idiomático que as tuplas tenham elementos que não sejam todos do mesmo tipo. Por esse motivo, as tuplas têm um caso especial no sistema de tipagem do Python. `tuple` aceita qualquer quantidade de argumentos de tipo:

    # OK: ``x`` foi atribuída a uma tupla de comprimento 1, onde o único elemento é um int
    x: tuple[int] = (5,)

    # OK: ``y`` foi atribuída a uma tupla de comprimento 2;
    # o elemento 1 é um int, o elemento 2 é uma str
    y: tuple[int, str] = (5, "foo")

    # Erro: a anotação de tipo indica uma tupla de comprimento 1,
    # mas ``z`` foi atribuída a uma tupla de comprimento 3
    z: tuple[int] = (1, 2, 3)

Para indicar um tupla que pode ser de qualquer comprimento, e no qual todos os elementos são do mesmo tipo `T`, use `tuple[T, ...]`. Para denotar um tupla vazia, use `tuple[()]`. Usando apenas `tuple` como anotação, é equivalente a usar `tuple[Any, ...]`:

    x: tuple[int, ...] = (1, 2)
    # Essas reatribuições são OK: ``tuple[int, ...]`` indica que x pode ter qualquer comprimento
    x = (1, 2, 3)
    x = ()
    # Essa reatribuição é um erro: todos os elementos de ``x`` devem ser ints
    x = ("foo", "bar")

    # ``y`` só pode ser atribuída a uma tupla vazia
    y: tuple[()] = ()

    z: tuple = ("foo", "bar")
    # Essas reatribuições são OK: o tipo ``tuple`` equivale a ``tuple[Any, ...]``
    z = (1, 2, 3)
    z = ()

## O tipo de objetos de classe

Uma variável anotada com `C` pode aceitar um valor de tipo `C`. Por outro lado, uma variável anotada com `type[C]` (ou o tipo descontinuado `typing.Type[C]`) pode aceitar valores que são as próprias classes – mais especificamente, ela aceitará o objeto classe de `C`. Por exemplo:

    a = 3         # Tem tipo ``int``
    b = int       # Tem tipo ``type[int]``
    c = type(a)   # Também tem tipo ``type[int]``

Observe que `type[C]` é covariante:

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

    def make_new_user(user_class: type[User]) -> User:
        # ...
        return user_class()

    make_new_user(User)      # OK
    make_new_user(ProUser)   # Também OK: ``type[ProUser]`` é subtipo de ``type[User]``
    make_new_user(TeamUser)  # Tudo bem
    make_new_user(User())    # Erro: esperava-se ``type[User]`` mas retornou ``User``
    make_new_user(int)       # Erro: ``type[int]`` não é subtipo de ``type[User]``

Os únicos parâmetros válidos para `type` são classes, `Any`, type variables e uniões de qualquer um desses tipos. Por exemplo:

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

    new_non_team_user(BasicUser)  # OK
    new_non_team_user(ProUser)    # OK
    new_non_team_user(TeamUser)   # Erro: ``type[TeamUser]`` não é subtipo
                                  # de ``type[BasicUser | ProUser]``
    new_non_team_user(User)       # Também é um erro

`type[Any]` é equivalente a `type`, que é a raiz da hierarquia de metaclasses do Python.

## Anotando geradores e corrotinas

Um gerador pode ser anotado usando um tipo genérico `Generator[YieldType, SendType, ReturnType]`. Por exemplo:

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

Note que, diferentemente de outras classes genéricas na biblioteca padrão, o ``SendType``da classe `Generator` se comporta contravariantemente, em vez de covariantemente ou invariantemente.

Os parâmetros `SendType` e `ReturnType` são `None` por padrão:

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

Também é possível definir esses tipos explicitamente:

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

Geradores simples que só produzem valores também podem ser anotados com tipo de retorno `Iterable[YieldType]` ou `Iterator[YieldType]`:

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

Geradores assíncronos são manipulados similarmente, mas não espere um argumento de tipo `ReturnType` (`AsyncGenerator[YieldType, SendType]`). O argumento `SendType` é `None` por padrão, então as seguintes definições são equivalentes:

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

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

Como no caso síncrono, `AsyncIterable[YieldType]` e `AsyncIterator[YieldType]` também estão disponíveis:

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

Corrotinas podem ser anotadas usando `Coroutine[YieldType, SendType, ReturnType]`. Argumentos genéricos correspondem àqueles da classe `Generator`, por exemplo:

    from collections.abc import Coroutine
    c: Coroutine[list[str], str, int]  # Uma corrotina defina em outro lugar
    x = c.send('hi')                   # Tipo inferido de 'x' é list[str]
    async def bar() -> None:
        y = await c                    # Tipo inferido de 'y' é int

## Tipos genéricos definidos pelo usuário

Uma classe definida pelo usuário pode ser definica como uma classe genérica.

    from logging import Logger

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

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

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

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

Esta sintaxe indica que o classe `LoggedVar` é parametrizada em torno de uma única type variable `T`. Isso também torna `T` válido como um tipo dentro do corpo da classe.

Classes genéricas implicitamente herdar de `Generic`. Para compatibilidade com Python 3.11 e versões inferiores, também é possível herdar explicitamente de `Generic` para indicar uma classe genérica:

    from typing import TypeVar, Generic

    T = TypeVar('T')

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

Classes genéricas têm métodos `__class_getitem__()`, o que significa que podem ser parametrizadas em tempo de execução (por exemplo, `LoggedVar[int]` abaixo):

    from collections.abc import Iterable

    def zero_all_vars(vars: Iterable[LoggedVar[int]]) -> None:
        for var in vars:
            var.set(0)

Um tipo genérico pode ter qualquer número de tipos de variáveis. Todas as variedades de `TypeVar` são permitidas como parâmetros para um tipo genérico:

    from typing import TypeVar, Generic, Sequence

    class WeirdTrio[T, B: Sequence[bytes], S: (int, str)]:
        ...

    OldT = TypeVar('OldT', contravariant=True)
    OldB = TypeVar('OldB', bound=Sequence[bytes], covariant=True)
    OldS = TypeVar('OldS', int, str)

    class OldWeirdTrio(Generic[OldT, OldB, OldS]):
        ...

Cada tipo dos argumentos para `Generic` devem ser distintos. Assim, os seguintes exemplos são inválidos:

    from typing import TypeVar, Generic
    ...

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

    T = TypeVar('T')

    class Pair(Generic[T, T]):   # INVÁLIDO
        ...

Classes genéricas podem também herdar de outras classes:

    from collections.abc import Sized

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

Ao herdar das classes genérico, algun tipos podem ser fixos:

    from collections.abc import Mapping

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

Neste caso `MyDict` possui um único parâmetro, `T`.

O uso de uma classe genérica sem especificar tipos pressupõe `Any` para cada posição. No exemplo a seguir, `MyIterable` não é genérico, mas herda implicitamente de `Iterable[Any]`:

    from collections.abc import Iterable

    class MyIterable(Iterable): # Igual a Iterable[Any]
        ...

Também há suporte para tipos genéricos definidos pelo usuário. Exemplos:

    from collections.abc import Iterable

    type Response[S] = Iterable[S] | int

    # Tipo de retorno aqui é igual a Iterable[str] | int
    def response(query: str) -> Response[str]:
        ...

    type Vec[T] = Iterable[tuple[T, T]]

    def inproduct[T: (int, float, complex)](v: Vec[T]) -> T: # Igual a Iterable[tuple[T, T]]
        return sum(x*y for x, y in v)

Para compatibilidade retroativa, os apelidos para tipos genéricos também podem ser criados por meio de um simples atribuição:

    from collections.abc import Iterable
    from typing import TypeVar

    S = TypeVar("S")
    Response = Iterable[S] | int

Alterado na versão 3.7: `Generic` não possui mais uma metaclasse personalizada.

Alterado na versão 3.12: Suporte sintático para apelidos de tipo e genéricos é novo na versão 3.12. Anteriormente, as classes genéricas precisavam explicitamente herdar de `Generic` ou conter um tipo de variável em uma de suas bases.

Genéricos definidos pelo usuário para expressões de parâmetros também oferecem suporte por meio de variáveis de especificação de parâmetros no formato `[**P]`. O comportamento é consistente com as variáveis de tipo descritas acima, pois as variáveis de especificação de parâmetro são tratadas pelo módulo typing como uma variável de tipo especializada. A única exceção a isso é que uma lista de tipos pode ser usada para substituir um `ParamSpec`:

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

Classes genéricas sobre um `ParamSpec` também podem ser criadas usando herança explícita de `Generic`. Neste caso, `**` não é usado:

    from typing import ParamSpec, Generic

    P = ParamSpec('P')

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

Outra diferença entre `TypeVar` e `ParamSpec` é que um genérico com apenas uma variável de especificação de parâmetro aceitará listas de parâmetros nos formatos `X[[Type1, Type2, ...]]` e também `X[Type1, Type2, ...]` por razões estéticas. Internamente, o último é convertido no primeiro, portanto são equivalentes:

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

Observe que genéricos com `ParamSpec` podem não ter `__parameters__` corretos após a substituição em alguns casos porque eles são destinados principalmente à verificação de tipo estático.

Alterado na versão 3.10: `Generic` agora pode ser parametrizado através de expressões de parâmetros. Veja `ParamSpec` e PEP 612 para mais detalhes.

Uma classe genérica definida pelo usuário pode ter ABCs como classes base sem conflito de metaclasse. Não há suporte a metaclasses genéricas. O resultado da parametrização de genéricos é armazenado em cache, e a maioria dos tipos no módulo typing são hasheáveis e comparáveis em termos de igualdade.

## O tipo `Any`

Um tipo especial de tipo é `Any`. Um verificador de tipo estático tratará cada tipo como sendo compatível com `Any` e `Any` como sendo compatível com todos os tipos.

Isso significa que é possível realizar qualquer operação ou chamada de método sobre um valor do tipo `Any` e atribuí-lo a qualquer variável:

    from typing import Any

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

    s: str = ''
    s = a           # OK

    def foo(item: Any) -> int:
        # Passa na verificação de tipos; 'item' pode ser qualquer tipo,
        # e esse tipo pode ter um método 'bar'
        item.bar()
        ...

Observe que nenhuma verificação de tipo é realizada ao atribuir um valor do tipo `Any` a um tipo mais preciso. Por exemplo, o verificador de tipo estático não relatou um erro ao atribuir `a` a `s` mesmo que `s` tenha sido declarado como sendo do tipo `str` e receba um valor `int` em tempo de execução!

Além disso, todas as funções sem um tipo de retorno ou tipos de parâmetro terão como padrão implicitamente o uso de `Any`:

    def legacy_parser(text):
        ...
        return data

    # Um verificador de tipo estático tratará a função acima
    # como tendo a mesma assinatura da função abaixo:
    def legacy_parser(text: Any) -> Any:
        ...
        return data

Este comportamento permite que `Any` seja usado como uma saída de emergência quando você precisar misturar código tipado dinamicamente e estaticamente.

Compare o comportamento de `Any` com o comportamento de `object`. Semelhante a `Any`, todo tipo é um subtipo de `object`. No entanto, ao contrário de `Any`, o inverso não é verdadeiro: `object` não é um subtipo de qualquer outro tipo.

Isso significa que quando o tipo de um valor é `object`, um verificador de tipo rejeitará quase todas as operações nele, e atribuí-lo a uma variável (ou usá-la como valor de retorno) de um tipo mais especializado é um tipo erro. Por exemplo:

    def hash_a(item: object) -> int:
        # Falha na verificação de tipo; um 'object' não tem um método 'magic'.
        item.magic()
        ...

    def hash_b(item: Any) -> int:
        # Passa na verificação de tipo
        item.magic()
        ...

    # Passa na verificação de tipo, já que ints e strs são subclasses de 'object'
    hash_a(42)
    hash_a("foo")

    # Passa na verificação de tipo, já que Any é compatível com todos os tipos
    hash_b(42)
    hash_b("foo")

Use `object` para indicar que um valor pode ser de qualquer tipo de maneira segura. Use `Any` para indicar que um valor é tipado dinamicamente.

## Subtipagem nominal vs estrutural

Inicialmente a PEP 484 definiu o sistema de tipos estáticos do Python como usando subtipagem nominal. Isto significa que uma classe `A` é permitida onde uma classe `B` é esperada se e somente se `A` for uma subclasse de `B`.

Este requisito anteriormente também se aplicava a classes base abstratas, como `Iterable`. O problema com essa abordagem é que uma classe teve que ser marcada explicitamente para suportá-los, o que não é pythônico e diferente do que normalmente seria feito em código Python de tipo dinamicamente idiomático. Por exemplo, isso está em conformidade com PEP 484:

    from collections.abc import Sized, Iterable, Iterator

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

PEP 544 permite resolver este problema permitindo que os usuários escrevam o código acima sem classes base explícitas na definição de classe, permitindo que `Bucket` seja implicitamente considerado um subtipo de `Sized` e `Iterable[int]` por verificador de tipo estático. Isso é conhecido como subtipagem estrutural (ou tipagem pato estática):

    from collections.abc import Iterator, Iterable

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

    def collect(items: Iterable[int]) -> int: ...
    result = collect(Bucket())  # Passa na verificação de tipo

Além disso, ao criar uma subclasse de uma classe especial `Protocol`, um usuário pode definir novos protocolos personalizados para aproveitar ao máximo a subtipagem estrutural (veja exemplos abaixo).

## Conteúdo do módulo

O módulo `typing` define as seguintes classes, funções e decoracores.

### Tipos primitivos especiais

#### Tipos especiais

Eles podem ser usados como tipos em anotações. Eles não oferecem suporte a subscrição usando `[]`.

typing.Any

  Tipo especial que indica um tipo irrestrito.

  - Todos os tipos são compatíveis com `Any`.

  - `Any` é compatível com todos os tipos.

  Alterado na versão 3.11: `Any` agora pode ser usado como classe base. Isso pode ser útil para evitar erros do verificador de tipo com classes que podem digitar em qualquer lugar ou são altamente dinâmicas.

typing.AnyStr

  Uma variável de tipo restrito.

  Definição:

      AnyStr = TypeVar('AnyStr', str, bytes)

  `AnyStr` deve ser usado para funções que podem aceitar argumentos `str` ou `bytes` 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 tipo `Any`, nem significa “qualquer string”. Em particular, `AnyStr` e `str | 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 importar `AnyStr`. Veja a PEP 695 para mais detalhes.

  No Python 3.16, `AnyStr` será removido de `typing.__all__`, e avisos de descontinuação serão emitidos em tempo de execução quando ele for acessado ou importado de `typing`. `AnyStr` será removido do `typing` no Python 3.18.

typing.LiteralString

  Tipo especial que inclui apenas strings literais.

  Qualquer literal de string é compatível com `LiteralString`, assim como outro `LiteralString`. Entretanto, um objeto digitado apenas `str` não é. Uma string criada pela composição de objetos do tipo `LiteralString` também é aceitável como uma `LiteralString`.

  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` e `NoReturn` 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` e `NoReturn` 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 usar `Self` como anotação de retorno. Se `Foo.return_self` foi anotado como retornando `"Foo"`, então o verificador de tipo inferiria o objeto retornado de `SubclassOfFoo.return_self` como sendo do tipo `Foo` em vez de `SubclassOfFoo`.

  Outros casos de uso comuns incluem:

  - `classmethod`s que são usados como construtores alternativos e retornam instâncias do parâmetro `cls`.

  - 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ção `type`, que cria instâncias de `TypeAliasType` e que oferece suporte a nativamente referências futuras. Observe que embora `TypeAlias` e `TypeAliasType` sirvam propósitos semelhantes e tenham nomes semelhantes, eles são distintos e o último não é o tipo do primeiro. A remoção de `TypeAlias` não está planejada atualmente, mas os usuários são encorajados a migrar para instruções `type`.

#### 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 a `X | Y` e significa X ou Y.

  Para definir uma união, use, por exemplo. `Union[int, str]` ou a abreviatura `int | 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 a `X | None` (ou `Union[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 de `Optional` é 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 e `ParamSpec` para anotar um chamável de maior ordem que adiciona, remove ou transforma parâmetros de outro chamável. Seu uso é feito na forma `Concatenate[Arg1Type, Arg2Type, ..., ParamSpecVariable]`, `Concatenate` atualmente só é válido quando usado como primeiro argumento de um Callable. O último parâmetro de `Concatenate` deve ser um `ParamSpec` ou reticências (`...`).

  Por exemplo, para anotar um decorador `with_lock` que oferece uma instância de `threading.Lock` para a função decorada, `Concatenate` pode ser usado para indicar que `with_lock` espera um chamável cujo primeiro argumento tem tipo `Lock`, e retorna um chamável com uma assinatura de tipos diferente. Neste caso, o `ParamSpec` 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` e `Concatenate`)

  - `ParamSpec`

  - Anotações de objetos chamáveis

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 para `Literal[...]`, mas verificadores de tipo podem impor restrições. Veja PEP 586 para mais detalhes sobre tipos literais.

  Adicionado na versão 3.8.

  Alterado na versão 3.9.1: `Literal` agora remove parâmetros duplicados. Comparações de igualdade entre objetos `Literal` não dependem da ordem. Objetos `Literal` agora levantam uma exceção `TypeError` durante comparações de igualdade se um de seus parâmetros não for hasheável.

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 com `isinstance()` ou `issubclass()`. `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.

  Alterado na versão 3.13: `ClassVar` agora pode ser aninhada em `Final` e vice-versa.

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.

  Alterado na versão 3.13: `Final` agora pode ser aninhada em `ClassVar` e vice-versa.

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`. Veja `TypedDict` 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 tipo `T` usando a anotação `Annotated[T, x]`. Os metadados adicionados usando `Annotated` 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 como `T`. 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 de `T`, pois os verificadores de tipo simplesmente ignoram os metadados em `x`. Dessa forma, o `Annotated` difere do decorador `@no_type_check`, que também pode ser usado para adicionar anotações fora do escopo do sistema de tipagem, mas desativa completamente a verificação de tipos para uma função ou classe.

  The responsibility of how to interpret the metadata lies with the tool or library encountering an `Annotated` annotation. A tool or library encountering an `Annotated` type can scan through the metadata elements to determine if they are of interest (e.g., using `isinstance()`).

  Annotated[<type>, <metadata>]

  Here is an example of how you might use `Annotated` to add metadata to type annotations if you were doing range analysis:

      @dataclass
      class ValueRange:
          lo: int
          hi: int

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

  Detalhes da sintaxe:

  - O primeiro argumento de `Annotated` deve ser um tipo válido

  - Múltiplos elementos de metadados podem ser fornecidos (`Annotated` dá suporte a argumentos variádicos):

        @dataclass
        class ctype:
            kind: str

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

    It is up to the tool consuming the annotations to decide whether the client is allowed to add multiple metadata elements to one annotation and how to merge those annotations.

  - `Annotated` deve ser subscrito com pelo menos dois argumentos (`Annotated[int]` é inválido)

  - A ordem dos elementos de metadados é preservada e é importante em verificações de igualdade:

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

  - Os tipos `Annotated` aninhados são achatados. A ordem dos elementos de metadados começa com a anotação mais interna:

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

  - Elementos duplicados de metadata não são removidos:

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

  - `Annotated` pode ser usado com apelidos aninhados e apelidos genéricos:

        @dataclass
        class MaxLen:
            value: int

        type Vec[T] = Annotated[list[tuple[T, T]], MaxLen(10)]

        # When used in a type annotation, a type checker will treat "V" the same as
        # ``Annotated[list[tuple[int, int]], MaxLen(10)]``:
        type V = Vec[int]

  - `Annotated` não pode ser usado com um `TypeVarTuple` desempacotado:

        type Variadic[*Ts] = Annotated[*Ts, Ann1]  # INVÁLIDO

    Isso deve equivaler a:

        Annotated[T1, T2, T3, ..., Ann1]

    onde `T1`, `T2`, etc. são `TypeVars`. Isso seria inválido: somente um tipo deve ser passado para Annotated.

  - Por padrão, `get_type_hints()` retira os metadados de anotações. Passe `include_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óprio `Annotated`:

        >>> get_origin(Password)
        typing.Annotated

  Ver também

  PEP 593 - Anotações flexíveis para funções e variáveis

    A PEP que introduz `Annotated` à biblioteca padrão.

  Adicionado na versão 3.9.

typing.TypeIs

  Uma construção especial de tipagem para marcar funções de predicado de tipo definidas pelo usuário.

  `TypeIs` can be used to annotate the return type of a user-defined type predicate function. `TypeIs` only accepts a single type argument. At runtime, functions marked this way should return a boolean and take at least one positional argument.

  `TypeIs` aims to benefit type narrowing – a technique used by static type checkers to determine a more precise type of an expression within a program’s code flow. Usually type narrowing is done by analyzing conditional code flow and applying the narrowing to a block of code. The conditional expression here is sometimes referred to as a “type predicate”:

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

  Às vezes, seria conveniente usar uma função booleana definida pelo usuário como um predicado de tipo. Essa função deveria usar `TypeIs[...]` ou `TypeGuard` 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 que `TypeGuard`, mas não pode ser usado quando os tipos de entrada e saída são incompatíveis (por exemplo, de `list[object]` para `list[int]`) ou quando a função não retorna `True` para todas as instâncias do tipo restrito.

  Usar `-> TypeIs[NarrowedType]` informa ao verificador de tipo estático que, para uma determinada função:

  1. O valor de retorno é um booleano.

  2. Se o valor de retorno for `True`, o tipo de seu argumento será a interseção entre o tipo original do argumento e o `NarrowedType`.

  3. Se o valor de retorno for `False`, o tipo de seu argumento será restrito para excluir `NarrowedType`.

  Por exemplo:

      from typing import assert_type, final, TypeIs

      class Parent: pass
      class Child(Parent): pass
      @final
      class Unrelated: pass

      def is_parent(val: object) -> TypeIs[Parent]:
          return isinstance(val, Parent)

      def run(arg: Child | Unrelated):
          if is_parent(arg):
              # Tipo de ``arg`` é restrito à interseção
              # de ``Parent`` e ``Child``, o que equivale a
              # ``Child``.
              assert_type(arg, Child)
          else:
              # Tipo de ``arg`` é restrito para excluir ``Parent``,
              # então sobrou o tipo ``Unrelated``.
              assert_type(arg, Unrelated)

  The type inside `TypeIs` must be consistent with the type of the function’s argument; if it is not, static type checkers will raise an error. An incorrectly written `TypeIs` function can lead to unsound behavior in the type system; it is the user’s responsibility to write such functions in a type-safe manner.

  Se uma função `TypeIs` for um método de classe ou instância, então o tipo em `TypeIs` mapeia para o tipo do segundo parâmetro (depois de `cls` ou `self`).

  Em resumo, a forma `def foo(arg: TypeA) -> TypeIs[TypeB]: ...`, significa que se `foo(arg)` retorna `True`, então `arg` é um instância de `TypeB`, e se retorna `False`, não é um instância de `TypeB`.

  `TypeIs` também funciona com variáveis de tipo. Para mais informações, consulte a PEP 742 (Restringindo tipos com `TypeIs`).

  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 como `TypeIs`, 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:

  1. O valor de retorno é um booleano.

  2. Se o valor de retorno for `True`, o tipo de seu argumento é o tipo dentro de `TypeGuard`.

  `TypeGuard` also works with type variables. See PEP 647 for more details.

  Por exemplo:

      def is_str_list(val: list[object]) -> TypeGuard[list[str]]:
          '''Determina se todos os objetos na lista são strings'''
          return all(isinstance(x, str) for x in val)

      def func1(val: list[object]):
          if is_str_list(val):
              # Tipo de ``val`` é restrito a ``list[str]``.
              print(" ".join(val))
          else:
              # Tipo de ``val`` continua sendo ``list[object]``.
              print("Not a list of strings!")

  `TypeIs` e `TypeGuard` diferem das seguintes maneiras:

  - `TypeIs` exige que o tipo restrito seja um subtipo do tipo de entrada, enquanto o `TypeGuard`, não. O motivo principal é permitir coisas como restringir `list[object]` a `list[str]`, embora este não seja um subtipo daquele, já que `list` é invariante.

  - Quando uma função `TypeGuard` retorna `True`, os verificadores de tipo restringem o tipo da variável exatamente ao tipo `TypeGuard`. Quando uma função `TypeIs` retorna `True`, os verificadores de tipo podem inferir um tipo mais preciso combinando o tipo previamente conhecido da variável com o tipo `TypeIs`. (Tecnicamente, isso é conhecido como um tipo de interseção).

  - Quando uma função `TypeGuard` retorna `False`, os verificadores de tipo não podem restringir o tipo da variável. Quando uma função `TypeIs` retorna `False`, os verificadores de tipo podem restringir o tipo da variável para excluir o tipo `TypeIs`.

  Adicionado na versão 3.10.

typing.Unpack

  Operador de tipagem para marcar conceitualmente um objeto como tendo sido desempacotado.

  For example, using the unpack operator `*` on a type variable tuple is equivalent to using `Unpack` to mark the type variable tuple as having been unpacked:

      Ts = TypeVarTuple('Ts')
      tup: tuple[*Ts]
      # Efetivamente faz:
      tup: tuple[Unpack[Ts]]

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

      # In older versions of Python, TypeVarTuple and Unpack
      # are located in the `typing_extensions` backports package.
      from typing_extensions import TypeVarTuple, Unpack

      Ts = TypeVarTuple('Ts')
      tup: tuple[*Ts]         # Syntax error on Python <= 3.10!
      tup: tuple[Unpack[Ts]]  # Semantically equivalent, and backwards-compatible

  `Unpack` também pode ser usado com `typing.TypedDict` para a tipagem de `**kwargs` em uma assinatura de função:

      from typing import TypedDict, Unpack

      class Movie(TypedDict):
          name: str
          year: int

      # Esta função espera dois argumentos nomeados: `name` de tipo `str`
      # e `year` de tipo `int`.
      def foo(**kwargs: Unpack[Movie]): ...

  Consulte PEP 692 para obter mais detalhes sobre como usar `Unpack` para tipagem de `**kwargs`.

  Adicionado na versão 3.11.

#### Criando tipos genéricos e apelidos de tipo

The following classes should not be used directly as annotations. Their intended purpose is to be building blocks for creating generic types and type aliases.

Esses objetos podem ser criados por meio de sintaxe especial (listas de parâmetros de tipo e a instrução `type`). Para compatibilidade com Python 3.11 e versões anteriores, eles também podem ser criados sem a sintaxe dedicada, como documentado abaixo.

class typing.Generic

  Classe base abstrata para tipos genéricos

  Normalmente, um tipo genérico é declarado adicionando-se uma lista de parâmetros de tipo após o nome da classe:

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

  Essa classe herda implicitamente de `Generic`. A semântica em tempo de execução dessa sintaxe é discutida na Referência da Linguagem.

  Esta classe pode ser utilizada como segue:

      def lookup_name[X, Y](mapping: Mapping[X, Y], key: X, default: Y) -> Y:
          try:
              return mapping[key]
          except KeyError:
              return default

  Aqui os colchetes depois no nome da função indica uma função genérica.

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

      KT = TypeVar('KT')
      VT = TypeVar('VT')

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

class typing.TypeVar(name, *constraints, bound=None, covariant=False, contravariant=False, infer_variance=False, default=typing.NoDefault)

  Tipo variável.

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

      class Sequence[T]:  # T é um TypeVar
          ...

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

      class StrSequence[S: str]:  # S is a TypeVar bound to str
          ...

      class StrOrBytesSequence[A: (str, bytes)]:  # A is a TypeVar constrained to str or bytes
          ...

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

      T = TypeVar('T')  # Can be anything
      S = TypeVar('S', bound=str)  # Can be any subtype of str
      A = TypeVar('A', str, bytes)  # Must be exactly str or bytes

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

      def repeat[T](x: T, n: int) -> Sequence[T]:
          """Return a list containing n references to x."""
          return [x]*n

      def print_capitalized[S: str](x: S) -> S:
          """Print x capitalized, and return x."""
          print(x.capitalize())
          return x

      def concatenate[A: (str, bytes)](x: A, y: A) -> A:
          """Add two strings or bytes objects together."""
          return x + y

  Note that type variables can be bound, constrained, or neither, but cannot be both bound and constrained.

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

  Bound type variables and constrained type variables have different semantics in several important ways. Using a bound type variable means that the `TypeVar` will be solved using the most specific type possible:

      x = print_capitalized('a string')
      reveal_type(x)  # revealed type is str

      class StringSubclass(str):
          pass

      y = print_capitalized(StringSubclass('another string'))
      reveal_type(y)  # revealed type is StringSubclass

      z = print_capitalized(45)  # error: int is not a subtype of str

  Type variables can be bound to concrete types, abstract types (ABCs or protocols), and even unions of types:

      # Can be anything with an __abs__ method
      def print_abs[T: SupportsAbs](arg: T) -> None:
          print("Absolute value:", abs(arg))

      U = TypeVar('U', bound=str|bytes)  # Can be any subtype of the union str|bytes
      V = TypeVar('V', bound=SupportsAbs)  # Can be anything with an __abs__ method

  Using a constrained type variable, however, means that the `TypeVar` can only ever be solved as being exactly one of the constraints given:

      a = concatenate('one', 'two')
      reveal_type(a)  # revealed type is str

      b = concatenate(StringSubclass('one'), StringSubclass('two'))
      reveal_type(b)  # revealed type is str, despite StringSubclass being passed in

      c = concatenate('one', b'two')  # error: type variable 'A' can be either str or bytes in a function call, but not both

  Em tempo de execução, `isinstance(x, T)` levantará `TypeError`.

  __name__

    The name of the type variable.

  __covariant__

    Whether the type var has been explicitly marked as covariant.

  __contravariant__

    Whether the type var has been explicitly marked as contravariant.

  __infer_variance__

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

    Adicionado na versão 3.12.

  __bound__

    The bound of the type variable, if any.

    Alterado na versão 3.12: For type variables created through type parameter syntax, the bound is evaluated only when the attribute is accessed, not when the type variable is created (see Avaliação preguiçosa).

  __constraints__

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

    Alterado na versão 3.12: For type variables created through type parameter syntax, the constraints are evaluated only when the attribute is accessed, not when the type variable is created (see Avaliação preguiçosa).

  __default__

    The default value of the type variable, or `typing.NoDefault` if it has no default.

    Adicionado na versão 3.13.

  has_default()

    Return whether or not the type variable has a default value. This is equivalent to checking whether `__default__` is not the `typing.NoDefault` singleton, except that it does not force evaluation of the lazily evaluated default value.

    Adicionado na versão 3.13.

  Alterado na versão 3.12: Type variables can now be declared using the type parameter syntax introduced by PEP 695. The `infer_variance` parameter was added.

  Alterado na versão 3.13: Adiciona suporte a valores padrão.

class typing.TypeVarTuple(name, *, default=typing.NoDefault)

  Type variable tuple. A specialized form of type variable that enables variadic generics.

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

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

  Ou invocando o construtor `TypeVarTuple` explicitamente:

      T = TypeVar("T")
      Ts = TypeVarTuple("Ts")

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

  A normal type variable enables parameterization with a single type. A type variable tuple, in contrast, allows parameterization with an arbitrary number of types by acting like an arbitrary number of type variables wrapped in a tuple. For example:

      # T é limitado a int, Ts é limitado a ()
      # Valor retornado é (1,), que tem tipo tuple[int]
      move_first_element_to_last(tup=(1,))

      # T é limitado a int, Ts é limitado a (str,)
      # Valor retornado é ('spam', 1), que tem tipo tuple[str, int]
      move_first_element_to_last(tup=(1, 'spam'))

      # T é limitado a int, Ts é limitado a (str, float)
      # Valor retornado é ('spam', 3.0, 1), que tem tipo tuple[str, float, int]
      move_first_element_to_last(tup=(1, 'spam', 3.0))

      # Isso é um erro para o verificador de tipos (e falha em tempo de execução)
      # pois tuple[()] não é compatível com tuple[T, *Ts]
      # (pelo menos um elemento é necessário)
      move_first_element_to_last(tup=())

  Note the use of the unpacking operator `*` in `tuple[T, *Ts]`. Conceptually, you can think of `Ts` as a tuple of type variables `(T1, T2, ...)`. `tuple[T, *Ts]` would then become `tuple[T, *(T1, T2, ...)]`, which is equivalent to `tuple[T, T1, T2, ...]`. (Note that in older versions of Python, you might see this written using `Unpack` instead, as `Unpack[Ts]`.)

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

      x: Ts          # Inválido
      x: tuple[Ts]   # Inválido
      x: tuple[*Ts]  # O jeito correto

  Type variable tuples can be used in the same contexts as normal type variables. For example, in class definitions, arguments, and return types:

      class Array[*Shape]:
          def __getitem__(self, key: tuple[*Shape]) -> float: ...
          def __abs__(self) -> "Array[*Shape]": ...
          def get_shape(self) -> tuple[*Shape]: ...

  Type variable tuples can be happily combined with normal type variables:

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

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

      class Height: ...
      class Width: ...

      float_array_1d: Array[float, Height] = Array()     # Totally fine
      int_array_2d: Array[int, Height, Width] = Array()  # Yup, fine too

  However, note that at most one type variable tuple may appear in a single list of type arguments or type parameters:

      x: tuple[*Ts, *Ts]             # Inválido
      class Array[*Shape, *Shape]:  # Inválido
          pass

  Finally, an unpacked type variable tuple can be used as the type annotation of `*args`:

      def call_soon[*Ts](
          callback: Callable[[*Ts], None],
          *args: *Ts
      ) -> None:
          ...
          callback(*args)

  In contrast to non-unpacked annotations of `*args` - e.g. `*args: int`, which would specify that all arguments are `int` - `*args: *Ts` enables reference to the types of the individual arguments in `*args`. Here, this allows us to ensure the types of the `*args` passed to `call_soon` match the types of the (positional) arguments of `callback`.

  See PEP 646 for more details on type variable tuples.

  __name__

    The name of the type variable tuple.

  __default__

    The default value of the type variable tuple, or `typing.NoDefault` if it has no default.

    Adicionado na versão 3.13.

  has_default()

    Return whether or not the type variable tuple has a default value. This is equivalent to checking whether `__default__` is not the `typing.NoDefault` singleton, except that it does not force evaluation of the lazily evaluated default value.

    Adicionado na versão 3.13.

  Adicionado na versão 3.11.

  Alterado na versão 3.12: Type variable tuples can now be declared using the type parameter syntax introduced by PEP 695.

  Alterado na versão 3.13: Adiciona suporte a valores padrão.

class typing.ParamSpec(name, *, bound=None, covariant=False, contravariant=False, default=typing.NoDefault)

  Parameter specification variable. A specialized version of type variables.

  Em listas de parâmetros de tipo as especificações de parâmetros podem ser declaradas com dois asteriscos (`**`):

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

  Para compatibilidade com Python 3.11 e versões anteriores, os objetos `ParamSpec` também podem ser criados da seguinte forma:

      P = ParamSpec('P')

  Parameter specification variables exist primarily for the benefit of static type checkers. They are used to forward the parameter types of one callable to another callable – a pattern commonly found in higher order functions and decorators. They are only valid when used in `Concatenate`, or as the first argument to `Callable`, or as parameters for user-defined Generics. See `Generic` for more information on generic types.

  For example, to add basic logging to a function, one can create a decorator `add_logging` to log function calls. The parameter specification variable tells the type checker that the callable passed into the decorator and the new callable returned by it have inter-dependent type parameters:

      from collections.abc import Callable
      import logging

      def add_logging[T, **P](f: Callable[P, T]) -> Callable[P, T]:
          '''A type-safe decorator to add logging to a function.'''
          def inner(*args: P.args, **kwargs: P.kwargs) -> T:
              logging.info(f'{f.__name__} was called')
              return f(*args, **kwargs)
          return inner

      @add_logging
      def add_two(x: float, y: float) -> float:
          '''Add two numbers together.'''
          return x + y

  Without `ParamSpec`, the simplest way to annotate this previously was to use a `TypeVar` with bound `Callable[..., Any]`. However this causes two problems:

  1. O verificador de tipos não consegue verificar a função `inner`, porque `*args` e `**kwargs` precisam ter tipo `Any`.

  2. `cast()` may be required in the body of the `add_logging` decorator when returning the `inner` function, or the static type checker must be told to ignore the `return inner`.

  args
  kwargs

    Como `ParamSpec` capturar tanto parâmetros posicionais quanto parâmetros nomeados, `P.args` e `P.kwargs` podem ser usados para dividir um `ParamSpec` 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` e `P.kwargs` são instâncias, respectivamente, de `ParamSpecArgs` e `ParamSpecKwargs`.

  __name__

    O nome da especificação de parâmetros.

  __default__

    O valor padrão da especificação de parâmetro, ou `typing.NoDefault` se não tiver padrão.

    Adicionado na versão 3.13.

  has_default()

    Return whether or not the parameter specification has a default value. This is equivalent to checking whether `__default__` is not the `typing.NoDefault` singleton, except that it does not force evaluation of the lazily evaluated default value.

    Adicionado na versão 3.13.

  Variáveis de especificação de parâmetros criadas com `covariant=True` ou `contravariant=True` podem ser usadas para declarar tipos genéricos covariantes ou contravariantes. O argumento `bound` também é aceito, semelhante ao `TypeVar`. 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` e `Concatenate`)

  - `Concatenate`

  - Anotações de objetos chamáveis

typing.ParamSpecArgs
typing.ParamSpecKwargs

  Arguments and keyword arguments attributes of a `ParamSpec`. The `P.args` attribute of a `ParamSpec` is an instance of `ParamSpecArgs`, and `P.kwargs` is an instance of `ParamSpecKwargs`. They are intended for runtime introspection and have no special meaning to static type checkers.

  Chamar `get_origin()` em qualquer um desses objetos fará retornará o `ParamSpec` original:

      >>> from typing import ParamSpec, get_origin
      >>> P = ParamSpec("P")
      >>> get_origin(P.args) is P
      True
      >>> get_origin(P.kwargs) is P
      True

  Adicionado na versão 3.10.

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

  O tipo de apelidos de tipo criados pela instrução `type`.

  Exemplo:

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

  Adicionado na versão 3.12.

  __name__

    O nome do apelido de tipo:

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

  __module__

    O módulo na qual o apelido de tipo foi definido:

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

  __type_params__

    Os parâmetros de tipo do apelido de tipo, ou um tupla vazia se o apelido não for genérico:

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

  __value__

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

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

#### Outras diretivas especiais

These functions and classes should not be used directly as annotations. Their intended purpose is to be building blocks for creating and declaring types.

class typing.NamedTuple

  Typed version of `collections.namedtuple()`.

  Uso:

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

  Isso equivale a:

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

  Para dar um valor padrão a um campo, você pode atribuir um valor a ele no corpo da classe:

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

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

  Campos com valores padrão devem vir depois de quaisquer campos sem valores padrão.

  The resulting class has an extra attribute `__annotations__` giving a dict that maps the field names to the field types. (The field names are in the `_fields` attribute and the default values are in the `_field_defaults` attribute, both of which are part of the `namedtuple()` API.)

  Subclasses de `NamedTuple` também podem ter docstrings e métodos:

      class Employee(NamedTuple):
          """Representa um funcionário."""
          name: str
          id: int = 3

          def __repr__(self) -> str:
              return f'<Employee {self.name}, id={self.id}>'

  Subclasses de ``NamedTuple``podem ser genéricas:

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

  Backward-compatible usage:

      # For creating a generic NamedTuple on Python 3.11
      T = TypeVar("T")

      class Group(NamedTuple, Generic[T]):
          key: T
          group: list[T]

      # A functional syntax is also supported
      Employee = NamedTuple('Employee', [('name', str), ('id', int)])

  Alterado na versão 3.6: Adiciona suporte à sintaxe de anotação de variáveis da PEP 526.

  Alterado na versão 3.6.1: Adiciona suporte a valores padrão, métodos, e docstrings.

  Alterado na versão 3.8: Os atributos `_field_types` e `__annotations__` agora são dicionários regulares em vez de instâncias de `OrderedDict`.

  Alterado na versão 3.9: Remove o atributo `_field_types` em favor do atributo mais padrão `__annotations__` que tem as mesmas informações.

  Alterado na versão 3.11: Adicionado suporte a namedtuples genéricas.

  Deprecated since version 3.13, will be removed in version 3.15: A sintaxe de argumentos nomeados não documentados para criar classes NamedTuple (`NT = NamedTuple("NT", x=int)`) está descontinuado e será proibido na versão 3.15. Em vez disso, use a sintaxe baseada em classes ou a sintaxe funcional.

  Deprecated since version 3.13, will be removed in version 3.15: When using the functional syntax to create a NamedTuple class, failing to pass a value to the ‘fields’ parameter (`NT = NamedTuple("NT")`) is deprecated. Passing `None` to the ‘fields’ parameter (`NT = NamedTuple("NT", None)`) is also deprecated. Both will be disallowed in Python 3.15. To create a NamedTuple class with 0 fields, use `class NT(NamedTuple): pass` or `NT = NamedTuple("NT", [])`.

class typing.NewType(name, tp)

  Helper class to create low-overhead distinct types.

  Um tipo `NewType` é considerado um tipo distinto por um verificador de tipos. Porém, em tempo de execução, chamar ``NewType``retorna seu argumento sem modificações.

  Uso:

      UserId = NewType('UserId', int) # Declare o NewType "UserId"
      first_user = UserId(1) # "UserId" retorna o argumento inalterado em tempo de execução

  __module__

    O endereço módulo no qual o novo tipo é definido.

  __name__

    O nome do novo tipo.

  __supertype__

    O tipo na qual o novo tipo é baseado.

  Adicionado na versão 3.5.2.

  Alterado na versão 3.10: `NewType` agora é uma classe em vez de uma função.

class typing.Protocol(Generic)

  Classe base para classes de protocolo.

  Classes de protocolo são definidas assim:

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

  Essas classes são usadas principalmente com verificadores de tipo estático que reconhecem a subtipagem estrutural (tipagem pato estática). Por exemplo,:

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

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

      func(C())  # Passa na verificação de tipos

  See PEP 544 for more details. Protocol classes decorated with `runtime_checkable()` (described later) act as simple-minded runtime protocols that check only the presence of given attributes, ignoring their type signatures.

  Classes de protocolo podem ser genéricas. Por exemplo:

      class GenProto[T](Protocol):
          def meth(self) -> T:
              ...

  Em códigos que precisam ser compatíveis com Python 3.11 ou versões anteriores, protocolos genéricos podem ser escritos da seguinte forma:

      T = TypeVar("T")

      class GenProto(Protocol[T]):
          def meth(self) -> T:
              ...

  Adicionado na versão 3.8.

@typing.runtime_checkable

  Marca uma classe de protocolo como um protocolo de tempo de execução.

  Such a protocol can be used with `isinstance()` and `issubclass()`. This raises `TypeError` when applied to a non-protocol class. This allows a simple-minded structural check, very similar to “one trick ponies” in `collections.abc` such as `Iterable`. For example:

      @runtime_checkable
      class Closable(Protocol):
          def close(self): ...

      assert isinstance(open('/some/file'), Closable)

      @runtime_checkable
      class Named(Protocol):
          name: str

      import threading
      assert isinstance(threading.Thread(name='Bob'), Named)

  Nota

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

  Nota

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

  Adicionado na versão 3.8.

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

  Alterado na versão 3.12: The members of a runtime-checkable protocol are now considered “frozen” at runtime as soon as the class has been created. Monkey-patching attributes onto a runtime-checkable protocol will still work, but will have no impact on `isinstance()` checks comparing objects to the protocol. See “What’s new in Python 3.12” for more details.

class typing.TypedDict(dict)

  Uma construção especial para adicionar dicas de tipo a um dicionário. Em tempo de execução, é um simples `dict`.

  `TypedDict` declares a dictionary type that expects all of its instances to have a certain set of keys, where each key is associated with a value of a consistent type. This expectation is not checked at runtime but is only enforced by type checkers. Usage:

      class Point2D(TypedDict):
          x: int
          y: int
          label: str

      a: Point2D = {'x': 1, 'y': 2, 'label': 'good'}  # OK
      b: Point2D = {'z': 3, 'label': 'bad'}           # Falha na verificação de tipos

      assert Point2D(x=1, y=2, label='first') == dict(x=1, y=2, label='first')

  Um modo alternativo de criar um `TypedDict` é usando a sintaxe de chamada de função. O segundo argumento deve ser um `dict`:

      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 usando `NotRequired`:

      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 chave `label` 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 literais `False` ou `True` como valores do argumento `total`. `True` é o padrão, e todos os itens definidos no corpo da classe tornam-se obrigatórios.

  As chaves individuais de um `TypedDict` com `total=False` podem ser marcadas conforme necessário usando `Required`:

      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 tipos `TypedDict` usando a sintaxe baseada em classes. Modo de usar:

      class Point3D(Point2D):
          z: int

  `Point3D` tem três itens: `x`, `y` e `z`. Equivale a esta definição:

      class Point3D(TypedDict):
          x: int
          y: int
          z: int

  Um `TypedDict` não pode herdar de uma classe não `TypedDict`, exceto `Generic`. 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 de `Generic` 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 argumento `total`. 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 classe `TypedDict` atual, e não que a classe é semanticamente total. Por exemplo, um `TypedDict` com `__total__` definido como `True` pode ter chaves marcadas com `NotRequired`, ou pode herdar de outro `TypedDict` com `total=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__` e `Point2D.__optional_keys__` retornam objetos `frozenset` contendo chaves obrigatórias e opcionais, respectivamente.

    As chaves marcadas com `Required` sempre aparecerão em `__required_keys__` e as chaves marcadas com `NotRequired` sempre aparecerão em `__optional_keys__`.

    For backwards compatibility with Python 3.10 and below, it is also possible to use inheritance to declare both required and non-required keys in the same `TypedDict` . This is done by declaring a `TypedDict` with one value for the `total` argument and then inheriting from it in another `TypedDict` with a different value for `total`:

        >>> class Point2D(TypedDict, total=False):
        ...     x: int
        ...     y: int
        ...
        >>> class Point3D(Point2D):
        ...     z: int
        ...
        >>> Point3D.__required_keys__ == frozenset({'z'})
        True
        >>> Point3D.__optional_keys__ == frozenset({'x', 'y'})
        True

    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 o `TypedDict` 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 qualificador `ReadOnly`.

    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 qualificador `ReadOnly`.

    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` ou `NotRequired`. Consulte PEP 655.

  Alterado na versão 3.11: Adicionado suporte para `TypedDict`s genéricos.

  Alterado na versão 3.13: Removeu suporte para o método de argumento nomeado de criar `TypedDict`s.

  Alterado na versão 3.13: Adiciona suporte ao qualificador `ReadOnly`.

  Deprecated since version 3.13, will be removed in version 3.15: When using the functional syntax to create a TypedDict class, failing to pass a value to the ‘fields’ parameter (`TD = TypedDict("TD")`) is deprecated. Passing `None` to the ‘fields’ parameter (`TD = TypedDict("TD", None)`) is also deprecated. Both will be disallowed in Python 3.15. To create a TypedDict class with 0 fields, use `class TD(TypedDict): pass` or `TD = 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

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

  O tipo genérico `IO[AnyStr]` e suas subclasses `TextIO(IO[str])` e `BinaryIO(IO[bytes])` representam os tipos de fluxos de E/S, como os retornados por `open()`.

### Funções e decoradores

typing.cast(typ, val)

  Define um valor para um tipo.

  This returns the value unchanged. To the type checker this signals that the return value has the designated type, but at runtime we intentionally don’t check anything (we want this to be as fast as possible).

typing.assert_type(val, typ, /)

  Pede para um verificador de tipo estático confirmar se val tem tipo inferido typ.

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

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

      def greet(name: str) -> None:
          assert_type(name, str) # OK, o tipo inferido de `name` é `str`
          assert_type(name, int) # erro no verificador de tipos

  Esse função é útil para garantir que o verificador de tipos entende um script conforme as intenções do desenvolvedor:

      def complex_function(arg: object):
          # Do some complex type-narrowing logic,
          # after which we hope the inferred type will be `int`
          ...
          # Test whether the type checker correctly understands our function
          assert_type(arg, int)

  Adicionado na versão 3.11.

typing.assert_never(arg, /)

  Pede ao verificador de tipo estático para confirmar se uma linha de código é inalcançável.

  Exemplo:

      def int_or_str(arg: int | str) -> None:
          match arg:
              case int():
                  print("It's an int")
              case str():
                  print("It's a str")
              case _ as unreachable:
                  assert_never(unreachable)

  Here, the annotations allow the type checker to infer that the last case can never execute, because `arg` is either an `int` or a `str`, and both options are covered by earlier cases.

  If a type checker finds that a call to `assert_never()` is reachable, it will emit an error. For example, if the type annotation for `arg` was instead `int | str | float`, the type checker would emit an error pointing out that `unreachable` is of type `float`. For a call to `assert_never` to pass type checking, the inferred type of the argument passed in must be the bottom type, `Never`, and nothing else.

  Em tempo de execução, essa função levanta uma exceção quando chamada.

  Ver também

  Código inalcançável e verificação exaustiva têm mais informações sobre a verificação exaustiva com a tipagem estática.

  Adicionado na versão 3.11.

typing.reveal_type(obj, /)

  Pede para um verificador de tipo estático revelar o tipo inferido de uma expressão.

  When a static type checker encounters a call to this function, it emits a diagnostic with the inferred type of the argument. For example:

      x: int = 1
      reveal_type(x) # O tipo revelado é "builtins.int"

  Isso pode ser útil quando você deseja depurar como o verificador de tipos lida com um determinado trecho de código.

  At runtime, this function prints the runtime type of its argument to `sys.stderr` and returns the argument unchanged (allowing the call to be used within an expression):

      x = reveal_type(1)  # exibe "Runtime type is int"
      print(x)  # exibe "1"

  Note that the runtime type may be different from (more or less specific than) the type statically inferred by a type checker.

  Most type checkers support `reveal_type()` anywhere, even if the name is not imported from `typing`. Importing the name from `typing`, however, allows your code to run without runtime errors and communicates intent more clearly.

  Adicionado na versão 3.11.

@typing.dataclass_transform(*, eq_default=True, order_default=False, kw_only_default=False, frozen_default=False, field_specifiers=(), **kwargs)

  Um decorador que marca um objeto como tendo comportamento similar a uma `dataclass`.

  `dataclass_transform` may be used to decorate a class, metaclass, or a function that is itself a decorator. The presence of `@dataclass_transform()` tells a static type checker that the decorated object performs runtime “magic” that transforms a class in a similar way to `@dataclasses.dataclass`.

  Exemplo de uso com a função decoradora:

      @dataclass_transform()
      def create_model[T](cls: type[T]) -> type[T]:
          ...
          return cls

      @create_model
      class CustomerModel:
          id: int
          name: str

  Em uma classe base:

      @dataclass_transform()
      class ModelBase: ...

      class CustomerModel(ModelBase):
          id: int
          name: str

  Em uma metaclasse:

      @dataclass_transform()
      class ModelMeta(type): ...

      class ModelBase(metaclass=ModelMeta): ...

      class CustomerModel(ModelBase):
          id: int
          name: str

  The `CustomerModel` classes defined above will be treated by type checkers similarly to classes created with `@dataclasses.dataclass`. For example, type checkers will assume these classes have `__init__` methods that accept `id` and `name`.

  The decorated class, metaclass, or function may accept the following bool arguments which type checkers will assume have the same effect as they would have on the `@dataclasses.dataclass` decorator: `init`, `eq`, `order`, `unsafe_hash`, `frozen`, `match_args`, `kw_only`, and `slots`. It must be possible for the value of these arguments (`True` or `False`) to be statically evaluated.

  Os argumentos do decorador ``dataclass_transform``podem ser usados para personalizar os comportamentos padrão da classe, metaclasse, ou função decorada:

  Parâmetros:

    - eq_default (bool) – Indicates whether the `eq` parameter is assumed to be `True` or `False` if it is omitted by the caller. Defaults to `True`.

    - order_default (bool) – Indicates whether the `order` parameter is assumed to be `True` or `False` if it is omitted by the caller. Defaults to `False`.

    - kw_only_default (bool) – Indicates whether the `kw_only` parameter is assumed to be `True` or `False` if it is omitted by the caller. Defaults to `False`.

    - frozen_default (bool) –

      Indicates whether the `frozen` parameter is assumed to be `True` or `False` if it is omitted by the caller. Defaults to `False`.

      Adicionado na versão 3.12.

    - field_specifiers (tuple [ Callable [..., Any], ...]) – Especifica uma lista estática de classes ou funções compatíveis que descrevem campos, semelhante a `dataclasses.field()`. O valor padrão é `()`.

    - **kwargs (Any) – Outros argumentos nomeados arbitrários são aceitos para permitir possíveis futuras extensões.

  Verificadores de tipo reconhecem os seguintes parâmetros opcionais em especificadores de campos:

  Parâmetros reconhecidos para especificadores de campos
  Nome do parâmetro | Descrição
  --- | ---
  `init` | Indica se o campo deve ser incluído no método `__init__` sintetizado. Se não for especificado, o valor padrão de `init` é `True`.
  `default` | Fornece o valor padrão do campo.
  `default_factory` | Provides a runtime callback that returns the default value for the field. If neither `default` nor `default_factory` are specified, the field is assumed to have no default value and must be provided a value when the class is instantiated.
  `factory` | Um apelido para o parâmetro `default_factory` em especificadores de campos.
  `kw_only` | Indica se o campo deve ser marcado como somente-nomeado. Se verdadeiro, o campo será somente-nomeado. Se falso, não será somente-nomeado. Se não for especificado, será usado o valor do parâmetro `kw_only` do objeto decorado com `dataclass_transform` ou, se este não for especificado, será usado o valor de `kw_only_default` no `dataclass_transform`.
  `alias` | Fornece um nome alternativo para o campo. Esse nome alternativo é usado no método `__init__` sintetizado.

  At runtime, this decorator records its arguments in the `__dataclass_transform__` attribute on the decorated object. It has no other runtime effect.

  Consulte PEP 681 para mais detalhes.

  Adicionado na versão 3.11.

@typing.overload

  Decorador para criar funções e métodos sobrecarregados.

  The `@overload` decorator allows describing functions and methods that support multiple different combinations of argument types. A series of `@overload`-decorated definitions must be followed by exactly one non-`@overload`-decorated definition (for the same function/method).

  `@overload`-decorated definitions are for the benefit of the type checker only, since they will be overwritten by the non-`@overload`-decorated definition. The non-`@overload`-decorated definition, meanwhile, will be used at runtime but should be ignored by a type checker. At runtime, calling an `@overload`-decorated function directly will raise `NotImplementedError`.

  An example of overload that gives a more precise type than can be expressed using a union or a type variable:

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

  Consulte PEP 484 para mais detalhes e uma comparação com outras semânticas de tipagem.

  Alterado na versão 3.11: Funções sobrecarregadas agora podem ser introspeccionadas em tempo de execução usando `get_overloads()`.

typing.get_overloads(func)

  Retorna uma sequência de `@overload` -definições decoradas para func.

  func é o objeto função para a implementação da função sobrecarregada. Por exemplo, dada a definição de `process` na documentação de `@sobrecarga` , `get_overloads(process)` retornará uma sequência de três objetos função para as três sobrecargas definidas. Se for chamada em uma função sem sobrecargas, `get_overloads()` retornará uma sequência vazia.

  A função `get_overloads()` pode ser usada em tempo de execução para introspecção de uma função sobrecarregada.

  Adicionado na versão 3.11.

typing.clear_overloads()

  Apaga todas as sobrecargas registradas no registro interno.

  Isso pode ser usado para recuperar a memória usada pelo registro.

  Adicionado na versão 3.11.

@typing.final

  Um decorador para indicar métodos e classes finais.

  Decorating a method with `@final` indicates to a type checker that the method cannot be overridden in a subclass. Decorating a class with `@final` indicates that it cannot be subclassed.

  Por exemplo:

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

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

  Não há verificação em tempo de execução dessas propriedades. Veja PEP 591 para mais detalhes.

  Adicionado na versão 3.8.

  Alterado na versão 3.11: The decorator will now attempt to set a `__final__` attribute to `True` on the decorated object. Thus, a check like `if getattr(obj, "__final__", False)` can be used at runtime to determine whether an object `obj` has been marked as final. If the decorated object does not support setting attributes, the decorator returns the object unchanged without raising an exception.

@typing.no_type_check

  Decorador para indicar que anotações não são dicas de tipo.

  This works as a class or function decorator. With a class, it applies recursively to all methods and classes defined in that class (but not to methods defined in its superclasses or subclasses). Type checkers will ignore all annotations in a function or class with this decorator.

  `@no_type_check` modifica o objeto decorado internamente.

@typing.no_type_check_decorator

  Decorador para dar a outro decorador o efeito `no_type_check()`.

  Isso envolve o decorador com algo que envolve a função decorada em `no_type_check()`.

  Deprecated since version 3.13, will be removed in version 3.15: Nenhum verificador de tipos jamais adicionou suporte para `@no_type_check_decorator`. Portanto, ele está descontinuado e será removido no Python 3.15.

@typing.override

  Decorador para indicar que um método em uma subclasse deve sobrecarregar um método ou atributo em uma superclasse.

  Type checkers should emit an error if a method decorated with `@override` does not, in fact, override anything. This helps prevent bugs that may occur when a base class is changed without an equivalent change to a child class.

  Por exemplo:

      class Base:
          def log_status(self) -> None:
              ...

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

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

  Não há verificação desta propriedade em tempo de execução.

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

  Consulte PEP 698 para obter mais detalhes.

  Adicionado na versão 3.12.

@typing.type_check_only

  Decorador para marcar uma classe ou função como indisponível em tempo de execução.

  This decorator is itself not available at runtime. It is mainly intended to mark classes that are defined in type stub files if an implementation returns an instance of a private class:

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

      def fetch_response() -> Response: ...

  Observe que retornar instâncias de classes privadas não é recomendado. Normalmente, é preferível tornar essas classes públicas.

### Introspection helpers

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

  Retorna um dicionário contendo dicas de tipo para uma função, método, módulo ou objeto classe.

  Geralmente é o mesmo que `obj.__annotations__`, mas esta função faz as seguintes alterações no dicionário de anotações:

  - Forward references encoded as string literals or `ForwardRef` objects are handled by evaluating them in globalns, localns, and (where applicable) obj’s type parameter namespace. If globalns or localns is not given, appropriate namespace dictionaries are inferred from obj.

  - `None` é substituído por `types.NoneType`.

  - Se `@no_type_check` tiver sido aplicada a obj, um dicionário vazio será retornado.

  - If obj is a class `C`, the function returns a dictionary that merges annotations from `C`’s base classes with those on `C` directly. This is done by traversing `C.__mro__` and iteratively combining `__annotations__` dictionaries. Annotations on classes appearing earlier in the method resolution order always take precedence over annotations on classes appearing later in the method resolution order.

  - The function recursively replaces all occurrences of `Annotated[T, ...]` with `T`, unless include_extras is set to `True` (see `Annotated` for more information).

  Veja também `inspect.get_annotations()`, uma função de nível mais baixo que retorna anotações mais diretamente.

  Nota

  If any forward references in the annotations of obj are not resolvable or are not valid Python code, this function will raise an exception such as `NameError`. For example, this can happen with imported type aliases that include forward references, or with names imported under `if TYPE_CHECKING`.

  Alterado na versão 3.9: Adiciona o parâmetro `include_extras` como parte da PEP 593. Consulte a documentação em `Annotated` para obter mais informações.

  Alterado na versão 3.11: Previously, `Optional[t]` was added for function and method annotations if a default value equal to `None` was set. Now the annotation is returned unchanged.

typing.get_origin(tp)

  Obtenha o versão sem subscrição de um tipo: para um objeto cujo tipo tem a forma `X[Y, Z, ...]`, retorna `X` .

  Se `X` for um apelido do módulo typing para uma classe embutida ou classe de `collections`, ele será normalizado para a classe original. Se `X` for uma instância de `ParamSpecArgs` ou `ParamSpecKwargs`, retorna o `ParamSpec` subjacente. Retorna `None` para objetos incompatíveis.

  Exemplos:

      assert get_origin(str) is None
      assert get_origin(Dict[str, int]) is dict
      assert get_origin(Union[int, str]) is Union
      assert get_origin(Annotated[str, "metadata"]) is Annotated
      P = ParamSpec('P')
      assert get_origin(P.args) is P
      assert get_origin(P.kwargs) is P

  Adicionado na versão 3.8.

typing.get_args(tp)

  Obtenha os argumentos de tipos com todas as substituições realizadas: para um objeto cujo tipo tem a forma `X[Y, Z, ...]`, retorna `(Y, Z, ...)` .

  If `X` is a union or `Literal` contained in another generic type, the order of `(Y, Z, ...)` may be different from the order of the original arguments `[Y, Z, ...]` due to type caching. Return `()` for unsupported objects.

  Exemplos:

      assert get_args(int) == ()
      assert get_args(Dict[int, str]) == (int, str)
      assert get_args(Union[int, str]) == (int, str)

  Adicionado na versão 3.8.

typing.get_protocol_members(tp)

  Retorna o conjunto de membros definidos em um `Protocol`.

      >>> from typing import Protocol, get_protocol_members
      >>> class P(Protocol):
      ...     def a(self) -> str: ...
      ...     b: int
      >>> get_protocol_members(P) == frozenset({'a', 'b'})
      True

  Levanta `TypeError` para argumentos que não são protocolos.

  Adicionado na versão 3.13.

typing.is_protocol(tp)

  Determina se um tipo é um `Protocol`.

  Por exemplo:

      class P(Protocol):
          def a(self) -> str: ...
          b: int

      is_protocol(P)    # => True
      is_protocol(int)  # => False

  Adicionado na versão 3.13.

typing.is_typeddict(tp)

  Verifica se um tipo é um `TypedDict`.

  Por exemplo:

      class Film(TypedDict):
          title: str
          year: int

      assert is_typeddict(Film)
      assert not is_typeddict(list | str)

      # TypedDict is a factory for creating typed dicts,
      # not a typed dict itself
      assert not is_typeddict(TypedDict)

  Adicionado na versão 3.10.

class typing.ForwardRef

  Class used for internal typing representation of string forward references.

  For example, `List["SomeClass"]` is implicitly transformed into `List[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 em `list[ForwardRef("SomeClass")]` e, portanto, não serão resolvidos automaticamente para `list[SomeClass]`.

  Adicionado na versão 3.7.4.

typing.NoDefault

  Um objeto sinalizador usado para indicar que um parâmetro de tipo não possui valor-padrão. Por exemplo:

      >>> T = TypeVar("T")
      >>> T.__default__ is typing.NoDefault
      True
      >>> S = TypeVar("S", default=None)
      >>> S.__default__ is None
      True

  Adicionado na versão 3.13.

### Constante

typing.TYPE_CHECKING

  Uma constante especial presumida ser `True` por verificadores de tipo estático de terceiros. É `False` em tempo de execução.

  Uso:

      if TYPE_CHECKING:
          import expensive_mod

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

  A primeira anotação de tipo deve ser colocada entre aspas, tornando-a uma “referência ao futuro”, para esconder do interpretador a referência ao módulo `expensive_mod`. As anotações de tipos em variáveis locais não são avaliadas, então a segunda anotação não precisa ser colocada entre aspas.

  Nota

  Se `from __future__ import annotations` for usado, anotações não serão avaliadas no momento de definição de funções. Em vez disso, elas são armazenadas como string em `__annotations__`. Isso torna desnecessário o uso de aspas em anotações (consulte PEP 563).

  Adicionado na versão 3.5.2.

### Apelidos descontinuados

Este módulo define vários apelidos descontinuados de classes pré-existentes de classes da biblioteca padrão. Originalmente, elas eram incluídas no módulo typing para permitir a parametrização dessas classes genéricas usand `[]`. Porém, os apelidos se tornaram redundantes no Python 3.9, quando as classes pré-existentes correspondentes passaram a dar suporte a `[]` (veja PEP 585).

Os tipos redundantes estão descontinuados desde Python 3.9. No entanto, enquanto os apelidos podem ser removidos em algum momento, essa remoção desses apelidos não está planejada. Assim, nenhum aviso de descontinuação será enviado pelo interpretador para esses apelidos.

Se em algum momento decidirem remover esses apelidos descontinuados, um aviso de descontinuação será enviado pelo interpretador por, no mínimo, duas versões de lançamento antes da remoção. Os apelidos são garantidos a permanecerem no módulo typing sem avisos de descontinuação até, no mínimo, Python 3.14.

Verificadores de tipos são encorajados a sinalizar o uso de tipos descontinuados se o programa que estão verificando respeita uma versão mínima de Python 3.9 ou mais nova.

#### Apelidos de tipos embutidos

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

  Apelido descontinuado de `dict`.

  Note que, para anotar argumentos, prefere-se usar um tipo de coleção abstrata como `Mapping` em vez de `dict` ou `typing.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` ou `Iterable`, em vez de `list` ou `typing.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 de `set` ou `typing.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` e `Tuple` 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` ou `typing.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()` e `re.match()`.

  Esses tipos (e as funções correspondentes) são genéricas sobre `AnyStr`. `Pattern` pode ser especializado como `Pattern[str]` ou `Pattern[bytes]`; `Match` pode ser especializado como `Match[str]` ou `Match[bytes]`.

  Obsoleto desde a versão 3.9: Classes `Pattern` e `Match` de `re` 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 for `unicode`.

  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 de `Text`.

#### Apelidos de contêineres ABC em `collections.abc`.

class typing.AbstractSet(Collection[T_co])

  Apelido descontinuado de `collections.abc.Set`.

  Obsoleto desde a versão 3.9: `collections.abc.Set` agora oferece suporte a subscrição (`[]`). Consulte PEP 585 e Tipo Generic Alias.

class typing.ByteString(Sequence[int])

  Este tipo representa os tipos `bytes`, `bytearray` e `memoryview` de sequências de bytes.

  Deprecated since version 3.9, will be removed in version 3.14: Prefira `collections.abc.Buffer`, ou uma união como `bytes | bytearray | memoryview`.

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

  Apelido descontinuado de `collections.abc.Collection`.

  Adicionado na versão 3.6.

  Obsoleto desde a versão 3.9: `collections.abc.Collection` agora oferece suporte a subscrição (`[]`). Consulte PEP 585 e Tipo Generic Alias.

class typing.Container(Generic[T_co])

  Apelido descontinuado de `collections.abc.Container`.

  Obsoleto desde a versão 3.9: `collections.abc.Container` agora oferece suporte a subscrição (`[]`). Consulte PEP 585 e Tipo Generic Alias.

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

  Apelido descontinuado de `collections.abc.ItemsView`.

  Obsoleto desde a versão 3.9: `collections.abc.ItemsView` agora oferece suporte a subscrição (`[]`). Consulte PEP 585 e Tipo Generic Alias.

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

  Apelido descontinuado de `collections.abc.KeysView`.

  Obsoleto desde a versão 3.9: `collections.abc.KeysView` agora oferece suporte a subscrição (`[]`). Consulte PEP 585 e Tipo Generic Alias.

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

  Apelido descontinuado de `collections.abc.Mapping`.

  Obsoleto desde a versão 3.9: `collections.abc.Mapping` agora oferece suporte a subscrição (`[]`). Consulte PEP 585 e Tipo Generic Alias.

class typing.MappingView(Sized)

  Apelido descontinuado de `collections.abc.MappingView`.

  Obsoleto desde a versão 3.9: `collections.abc.MappingView` agora oferece suporte a subscrição (`[]`). Consulte PEP 585 e Tipo Generic Alias.

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

  Apelido descontinuado de `collections.abc.MutableMapping`.

  Obsoleto desde a versão 3.9: `collections.abc.MutableMapping` agora oferece suporte a subscrição (`[]`). Consulte PEP 585 e Tipo Generic Alias.

class typing.MutableSequence(Sequence[T])

  Apelido descontinuado de `collections.abc.MutableSequence`.

  Obsoleto desde a versão 3.9: `collections.abc.MutableSequence` agora oferece suporte a subscrição (`[]`). Consulte PEP 585 e Tipo Generic Alias.

class typing.MutableSet(AbstractSet[T])

  Apelido descontinuado de `collections.abc.MutableSet`.

  Obsoleto desde a versão 3.9: `collections.abc.MutableSet` agora oferece suporte a subscrição (`[]`). Consulte PEP 585 e Tipo Generic Alias.

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

  Apelido descontinuado de `collections.abc.Sequence`.

  Obsoleto desde a versão 3.9: `collections.abc.Sequence` agora oferece suporte a subscrição (`[]`). Consulte PEP 585 e Tipo Generic Alias.

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

  Apelido descontinuado de `collections.abc.ValuesView`.

  Obsoleto desde a versão 3.9: `collections.abc.ValuesView` agora oferece suporte a subscrição (`[]`). Consulte PEP 585 e Tipo Generic Alias.

#### Apelidos para ABCs assíncronas em `collections.abc`

class typing.Coroutine(Awaitable[ReturnType], Generic[YieldType, SendType, ReturnType])

  Apelido descontinuado de `collections.abc.Coroutine`.

  Consulte Anotando geradores e corrotinas para obter detalhes sobre como usar `collections.abc.Coroutine` e `typing.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` e `typing.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` e `typing.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 a `ParamSpec` e `Concatenate`. 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` e `typing.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 `typing` de coleções-padrão | 3.9 | Não definido (consulte apelidos descontinuados para mais informações) | PEP 585
`typing.ByteString` | 3.9 | 3.14 | gh-91896
`typing.Text` | 3.11 | Não definido | gh-92332
`typing.Hashable` e `typing.Sized` | 3.12 | Não definido | gh-94309
`typing.TypeAlias` | 3.12 | Não definido | PEP 695
`@typing.no_type_check_decorator` | 3.13 | 3.15 | gh-106309
`typing.AnyStr` | 3.13 | 3.18 | gh-105578