O que há de novo no Python 3.14

Editor:

Hugo van Kemenade

Esse artigo explica os novos recursos no Python 3.14. comparado ao 3.13.

Para detalhes completos, veja o changelog.

Ver também

PEP 745 – Cronograma de lançamento do Python 3.14

Nota

Os usuários de pré-lançamento devem estar cientes de que este documento está atualmente em forma de rascunho. Ele será atualizado substancialmente à medida que o Python 3.14 caminha para seu lançamento estável, portanto vale a pena conferir mesmo depois de ler as versões anteriores.

Resumo – destaques da versão

O Python 3.14 vai ser o lançamento estável mais recente da linguagem de programação Python, com uma mistura de alterações na linguagem, na implementação e na biblioteca padrão.

As maiores mudanças no implementação incluem as strings template (PEP 750), a avaliação adiada de anotações (PEP 649) e um novo tipo de interpretador que usa a chamada de cauda.

As alterações na biblioteca incluem o acréscimo de um novo módulo, annotationlib (PEP 749), para introspecção e empacotamento de anotações (PEP 649), um novo módulo, compression.zstd, para suporte ao Zstandard (PEP 784), além de destaque de sintaxe no REPL, bem como descontinuações e remoções habituais e melhorias na facilidade de uso e correções.

Alterações incompatíveis

Em plataformas diferentes de macOS e Windows, o método de início padrão para multiprocessing e ProcessPoolExecutor muda de fork para forkserver.

Consulte (1) e (2) para detalhes.

Se você encontrar NameErrors ou erros de serialização com pickle vindos de multiprocessing ou concurrent.futures, consulte as restrições do forkserver.

O interpretador evita algumas modificações na contagem de referências internamente quando é seguro fazê-lo. Isso pode levar a valores diferentes retornados de sys.getrefcount() e Py_REFCNT() em comparação com versões anteriores do Python. Consulte abaixo para obter detalhes.

Novas funcionalidades

PEP 779: Python com threads livres é oficialmente suportado

A construção do Python com threads livres agora é suportada e não mais experimental. Este é o início da fase II, na qual o Python com threads livres é oficialmente suportado, mas ainda é opcional.

Estamos confiantes de que o projeto está no caminho certo e agradecemos a dedicação contínua de todos que trabalham para deixar o modo threads livres pronto para uma adoção mais ampla na comunidade Python.

Com essas recomendações e a aceitação desta PEP, nós, como comunidade de desenvolvedores Python, devemos anunciar amplamente que threads livres é uma opção de construção do Python suportada agora e no futuro, e que ela não será removida sem um cronograma de descontinuação adequado.

Qualquer decisão de transição para a fase III, com o uso de threads livres como versão padrão ou única do Python, ainda está indefinida e depende de muitos fatores, tanto dentro do próprio CPython quanto da comunidade. Esta decisão é para o futuro.

Ver também

PEP 779 e sua aceitação.

PEP 734: múltiplos interpretadores na stdlib

O ambiente de execução do CPython permite a execução simultânea de várias cópias do Python no mesmo processo, há mais de 20 anos. Cada uma dessas cópias separadas é chamada de “interpretador”. No entanto, o recurso estava disponível apenas por meio da API C.

Essa limitação foi removida na versão 3.14, com o novo módulo concurrent.interpreters.

Há pelo menos dois motivos importantes pelos quais vale a pena considerar o uso de múltiplos interpretadores:

  • eles oferecem suporte a um novo modelo (para Python) de simultaneidade, amigável ao ser humano

  • verdadeiro paralelismo multi-core

Para alguns casos de uso, a simultaneidade em software permite eficiência e pode simplificar o software em alto nível. Ao mesmo tempo, implementar e manter todos os tipos de simultaneidade, exceto as mais simples, costuma ser uma luta para o cérebro humano. Isso se aplica especialmente a threads simples (por exemplo, threading), onde toda a memória é compartilhada entre todas as threads.

Com múltiplos interpretadores isolados, você pode aproveitar uma classe de modelos de simultaneidade, como CSP ou o modelo de ator, que obtiveram sucesso em outras linguagens de programação, como Smalltalk, Erlang, Haskell e Go. Pense em múltiplos interpretadores como threads, mas com compartilhamento opt-in.

Sobre o paralelismo multinúcleo: a partir da versão 3.12, os interpretadores agora estão suficientemente isolados uns dos outros para serem usados em paralelo. (Veja PEP 684.) Isso destrava uma variedade de casos de uso intensivos de CPU para Python que eram limitados pela GIL.

O uso de múltiplos interpretadores é semelhante em muitos aspectos ao multiprocessing, pois ambos fornecem “processos” lógicos isolados que podem ser executados em paralelo, sem compartilhamento por padrão. No entanto, ao usar múltiplos interpretadores, uma aplicação usará menos recursos do sistema e operará com mais eficiência (já que permanece dentro do mesmo processo). Pense em múltiplos interpretadores como se tivessem o isolamento de processos com a eficiência de threads.

Embora o recurso já exista há décadas, múltiplos interpretadores não têm sido amplamente utilizados devido à baixa conscientização e à ausência de um módulo da stdlib. Consequentemente, eles atualmente apresentam diversas limitações notáveis, que melhorarão significativamente agora que o recurso finalmente está se tornando popular.

Limitações atuais:

  • iniciar cada interpretador ainda não foi otimizado

  • cada interpretador usa mais memória do que o necessário (trabalharemos em seguida no compartilhamento interno extensivo entre interpretadores)

  • não há muitas opções ainda para realmente compartilhar objetos ou outros dados entre interpretadores (além de memoryview)

  • muitos módulos de extensão no PyPI ainda não são compatíveis com múltiplos interpretadores (os módulos de extensão stdlib são compatíveis)

  • a abordagem para escrever aplicações que usam vários interpretadores isolados é, em grande parte, desconhecida para usuários do Python, por enquanto

O impacto dessas limitações dependerá de futuras melhorias no CPython, do uso dos interpretadores e do que a comunidade resolver por meio dos pacotes PyPI. Dependendo do caso de uso, as limitações podem não ter muito impacto, então experimente!

Além disso, versões futuras do CPython reduzirão ou eliminarão a sobrecarga e fornecerão utilitários menos apropriados no PyPI. Enquanto isso, a maioria das limitações também pode ser solucionada por meio de módulos de extensão, o que significa que os pacotes do PyPI podem preencher qualquer lacuna da versão 3.14 e até mesmo da versão 3.12, onde os interpretadores foram finalmente isolados adequadamente e pararam de compartilhar a GIL. Da mesma forma, esperamos ver gradualmente bibliotecas no PyPI para abstrações de alto nível sobre os interpretadores.

Em relação aos módulos de extensão, estamos trabalhando para atualizar alguns projetos PyPI, bem como ferramentas como Cython, pybind11, nanobind e PyO3. As etapas para isolar um módulo de extensão podem ser encontradas em Isolando módulos de extensão. O isolamento de um módulo tem muitas sobreposições com o que é necessário para oferecer suporte a threads livres, portanto, o trabalho contínuo da comunidade nessa área ajudará a acelerar o suporte a múltiplos interpretadores.

Também adicionado no 3.14: concurrent.futures.InterpreterPoolExecutor.

Ver também

PEP 734.

PEP 750: strings template

Literais de string template (t-strings) são uma generalização de f-strings, usando um t no lugar do prefixo f. Em vez de serem avaliadas como str, as t-strings são avaliadas como um novo tipo string.templatelib.Template:

from string.templatelib import Template

name = "Mundo"
template: Template = t"Olá {name}"

O modelo pode então ser combinado com funções que operam na estrutura do template para produzir um str ou um resultado semelhante a uma string. Por exemplo, sanitizando a entrada:

evil = "<script>alert('evil')</script>"
template = t"<p>{evil}</p>"
assert html(template) == "<p>&lt;script&gt;alert('evil')&lt;/script&gt;</p>"

Como outro exemplo, gerando atributos HTML a partir de dados:

attributes = {"src": "shrubbery.jpg", "alt": "looks nice"}
template = t"<img {attributes}>"
assert html(template) == '<img src="shrubbery.jpg" alt="looks nice" />'

Em comparação com o uso de uma f-string, a função html tem acesso a atributos de modelo que contêm as informações originais: strings estáticas, interpolações e valores do escopo original. Ao contrário das abordagens de modelo existentes, as t-strings são construídas a partir da sintaxe e das regras conhecidas das f-strings. Os sistemas de template, portanto, se beneficiam das ferramentas Python, pois estão muito mais próximos da linguagem Python, da sintaxe, do escopo e de outros aspectos.

Escrever manipuladores de template é simples:

from string.templatelib import Template, Interpolation

def lower_upper(template: Template) -> str:
    """Renderiza as partes estáticas em minúsculas e as interpolações em maiúsculas."""
    parts: list[str] = []
    for item in template:
        if isinstance(item, Interpolation):
            parts.append(str(item.value).upper())
        else:
            parts.append(item.lower())
    return "".join(parts)

name = "mundo"
assert lower_upper(t"OLÁ {name}") == "olá MUNDO"

Com isso, os desenvolvedores podem escrever sistemas de modelo para higienizar SQL, fazer operações de shell seguras, melhorar o registro, abordar ideias modernas em desenvolvimento web (HTML, CSS e assim por diante) e implementar DSLs comerciais leves e personalizadas.

(Contribuição de Jim Baker, Guido van Rossum, Paul Everitt, Koudai Aono, Lysandros Nikolaou, Dave Peck, Adam Turner, Jelle Zijlstra, Bénédikt Tran e Pablo Galindo Salgado em gh-132661.)

Ver também

PEP 750.

PEP 768: interface segura para depurador externo para o CPython

PEP 768 introduz uma interface de depuração sem sobrecarga que permite que depuradores e profilers se conectem com segurança a processos Python em execução. Esta é uma melhoria significativa nos recursos de depuração do Python, permitindo que depuradores renunciem a alternativas inseguras. Veja abaixo para saber como este recurso é utilizado para implementar os recursos de conexão remota do novo módulo pdb.

A nova interface fornece pontos de execução seguros para anexar código do depurador sem modificar o caminho de execução normal do interpretador ou adicionar sobrecarga de tempo de execução. Isso permite que as ferramentas inspecionem e interajam com aplicações Python em tempo real sem interrompê-las ou reiniciá-las — um recurso crucial para sistemas de alta disponibilidade e ambientes de produção.

Para conveniência, o CPython implementa essa interface por meio do módulo sys com uma função sys.remote_exec():

sys.remote_exec(pid, script_path)

Esta função permite o envio de código Python para ser executado em um processo de destino no próximo ponto de execução seguro. No entanto, os autores da ferramenta também podem implementar o protocolo diretamente, conforme descrito no PEP, que detalha os mecanismos subjacentes usados para anexar com segurança a processos em execução.

Aqui está um exemplo simples que inspeciona tipos de objetos em um processo Python em execução:

import os
import sys
import tempfile

# Cria um script temporário
with tempfile.NamedTemporaryFile(mode='w', suffix='.py', delete=False) as f:
    script_path = f.name
    f.write(f"import my_debugger; my_debugger.connect({os.getpid()})")
try:
    # Executa no processo com PID 1234
    print("Vejam! Eis uma oferta!:")
    sys.remote_exec(1234, script_path)
finally:
    os.unlink(script_path)

A interface de depuração foi cuidadosamente projetada com a segurança em mente e inclui vários mecanismos para controlar o acesso:

Um detalhe importante da implementação é que a interface se baseia no laço de avaliação existente do interpretador e nos pontos seguros, garantindo sobrecarga zero durante a execução normal e, ao mesmo tempo, fornecendo uma maneira confiável para processos externos coordenarem operações de depuração.

(Contribuição de Pablo Galindo Salgado, Matt Wozniski e Ivona Stojanovic em gh-131591.)

Ver também

PEP 768.

PEP 784: adicionando Zstandard à biblioteca padrão

O novo pacote compression contém os módulos compression.lzma, compression.bz2, compression.gzip e compression.zlib, que reexportam os módulos lzma, bz2, gzip e zlib, respectivamente. Os novos nomes de importação em compression são os nomes canônicos para a importação desses módulos de compactação daqui para frente. No entanto, os nomes dos módulos existentes não foram descontinuados. Qualquer descontinuação ou remoção dos módulos de compressão existentes ocorrerá no máximo cinco anos após o lançamento da versão 3.14.

O novo módulo compression.zstd fornece APIs de compactação e descompactação para o formato Zstandard por meio de ligações à biblioteca zstd do Meta. O Zstandard é um formato de compactação amplamente adotado, altamente eficiente e rápido. Além das APIs introduzidas em compression.zstd, o suporte para leitura e gravação de arquivos compactados do Zstandard foi adicionado aos módulos tarfile, zipfile e shutil.

Aqui está um exemplo de uso do novo módulo para compactar alguns dados:

from compression import zstd
import math

data = str(math.pi).encode() * 20

compressed = zstd.compress(data)

ratio = len(compressed) / len(data)
print(f"Foi alcançada uma taxa de compactação de {ratio}")

Como pode ser visto, a API é semelhante às APIs dos módulos lzma e bz2.

(Contribuição de Emma Harper Smith, Adam Turner, Gregory P. Smith, Tomas Roun, Victor Stinner e Rogdham em gh-132983.)

Ver também

PEP 784.

Anexação remota a um processo Python em execução com PDB

O módulo pdb agora suporta anexação remota a um processo Python em execução usando uma nova opção de linha de comando -p PID:

python -m pdb -p 1234

Isso se conectará ao processo Python com o PID fornecido e permitirá que você o depure interativamente. Observe que, devido ao funcionamento do interpretador Python, a conexão a um processo remoto bloqueado em uma chamada de sistema ou aguardando E/S só funcionará quando a próxima instrução de bytecode for executada ou quando o processo receber um sinal.

Este recurso usa PEP 768 e a função sys.remote_exec() para anexar ao processo remoto e enviar os comandos PDB a ele.

(Contribuição de Matt Wozniski e Pablo Galindo em gh-131591.)

Ver também

PEP 768.

PEP 758 – permite expressões except e except* sem parênteses

As expressões except e except* agora permitem a omissão de parênteses quando há vários tipos de exceção e a cláusula as não é usada. Por exemplo, as seguintes expressões agora são válidas:

try:
    connect_to_server()
except TimeoutError, ConnectionRefusedError:
    print("Problema de rede encontrado.")

 # O mesmo se aplica a except* (para grupos de exceções):

try:
    connect_to_server()
except* TimeoutError, ConnectionRefusedError:
    print("Problema de rede encontrado.")

Confira PEP 758 para mais detalhes.

(Contribuição de Pablo Galindo e Brett Cannon em gh-131831.)

Ver também

PEP 758.

PEP 649 e 749: avaliação adiada de anotações

As anotações em função, classes e módulos não são mais avaliados de forma ansiosa. Em vez disso, as anotações são armazenadas em uma função de anotação com propósito especial e avaliadas somente quando necessário (exceto se from __future__ import annotations for usado). Isso está especificado nas PEP 649 e PEP 749.

Essa alteração foi projetada para tornar anotações em Python mais eficientes e mais utilizáveis na maioria das circunstâncias. O custo em tempo de execução para definir anotação é minimizado, mas continua sendo possível introspectar anotação em tempo de execução. Não é mais necessário incluir anotação em string se eles contiverem referência futura.

O novo módulo annotationlib fornece ferramentas para inspecionar anotação adiada. A anotação pode ser avaliada nos formatos VALUE (que avalia anotações para valores em tempo de execução, semelhante ao comportamento nas versões anteriores do Python), FORWARDREF (que substitui nomes indefinidos por marcadores especiais) e STRING (que retorna anotações como strings).

Este exemplo mostra como esses formatos se comportam:

>>> from annotationlib import get_annotations, Format
>>> def func(arg: Undefined):
...     pass
>>> get_annotations(func, format=Format.VALUE)
Traceback (most recent call last):
  ...
NameError: name 'Undefined' is not defined
>>> get_annotations(func, format=Format.FORWARDREF)
{'arg': ForwardRef('Undefined', owner=<function func at 0x...>)}
>>> get_annotations(func, format=Format.STRING)
{'arg': 'Undefined'}

Implicações para o código anotado

Se você definir anotação em seu código (por exemplo, para uso com um verificador de tipo estático), essa alteração provavelmente não o afetará: você pode continuar escrevendo anotação da mesma forma que fazia com as versões anteriores de Python.

É provável que você consiga remover as strings entre aspas em anotações, que são frequentemente usadas para referência futura. Da mesma forma, se você usar from __future__ import annotations para evitar ter que escrever string em anotação, poderá remover essa importação se você for manter seu código apenas para Python 3.14 e mais recentes. No entanto, se você depende de bibliotecas de terceiros que leem anotações, essas bibliotecas podem precisar de alterações no suporte a anotações sem aspas para funcionaram como esperado.

Implicações para leitores de __annotations__

Se o seu código lê o atributo __annotations__ dos objetos, talvez você queira fazer alterações para prover suporte a código que depende da avaliação adiada de anotações. Por exemplo, talvez você queira usar annotationlib.get_annotations() com o formato FORWARDREF, como o módulo dataclasses faz agora.

O pacote externo typing_extensions fornece compatibilidade retroativa parcial de algumas das funcionalidades do módulo annotationlib, como a enumeração Format e a função get_annotations(). Eles podem ser usados para escrever código com versão-cruzada que aproveite as vantagens do novo comportamento em Python 3.14.

from __future__ import annotations

No Python 3.7, a PEP 563 introduziu a diretiva from __future__ import annotations, que transforma todas as anotações em strings. Essa diretiva agora é considerada descontinuada e espera-se que seja removida em uma futura versão do Python. No entanto, essa remoção só ocorrerá depois que Python 3.13, a última versão sem avaliação adiada de anotação, chegar ao fim de sua vida útil em 2029. No Python 3.14, o comportamento do código que usa from __future__ import annotations não foi alterado.

(Contribuição de Jelle Zijlstra em gh-119180, PEP 649 foi escrita por Larry Hastings.)

Ver também

PEP 649 e PEP 749.

Mensagens de erro melhoradas

  • O interpretador agora fornece sugestões úteis ao detectar erros de digitação em palavras reservadas do Python. Ao encontrar uma palavra que se assemelha muito a uma palavra reservada do Python, o interpretador sugere a palavra reservada correta na mensagem de erro. Esse recurso ajuda os programadores a identificar e corrigir rapidamente erros comuns de digitação. Por exemplo:

    >>> whille True:
...     pass
Traceback (most recent call last):
  File "<stdin>", line 1
    whille True:
    ^^^^^^
SyntaxError: invalid syntax. Did you mean 'while'?

>>> asynch def fetch_data():
...     pass
Traceback (most recent call last):
  File "<stdin>", line 1
    asynch def fetch_data():
    ^^^^^^
SyntaxError: invalid syntax. Did you mean 'async'?

>>> async def foo():
...     awaid fetch_data()
Traceback (most recent call last):
  File "<stdin>", line 2
    awaid fetch_data()
    ^^^^^
SyntaxError: invalid syntax. Did you mean 'await'?

>>> raisee ValueError("Error")
Traceback (most recent call last):
  File "<stdin>", line 1
    raisee ValueError("Error")
    ^^^^^^
SyntaxError: invalid syntax. Did you mean 'raise'?

    Embora o recurso se concentre nos casos mais comuns, algumas variações de erros ortográficos ainda podem resultar em erros de sintaxe comuns. (Contribuição de Pablo Galindo em gh-132449.)

  • Quando uma atribuição de desempacotamento falha devido a um número incorreto de variáveis, a mensagem de erro exibe o número de valores recebidos em mais casos do que antes. (Contribuição de Tushar Sadhwani em gh-122239.)

    >>> x, y, z = 1, 2, 3, 4
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
    x, y, z = 1, 2, 3, 4
    ^^^^^^^
ValueError: too many values to unpack (expected 3, got 4)

  • Instruções elif que seguem um bloco else agora têm uma mensagem de erro específica. (Contribuição de Steele Farnsworth em gh-129902.)

    >>> if who == "eu":
...     print("Sou eu!")
... else:
...     print("Não sou eu!")
... elif who is None:
...     print("Quem é?")
File "<stdin>", line 5
  elif who is None:
  ^^^^
SyntaxError: 'elif' block follows an 'else' block

  • Se uma instrução (pass, del, return, yield, raise, break, continue, assert, import, from) for passada para Expressões condicionais após else, ou uma dentre pass, break ou continue for passada antes de if, a mensagem de erro destacará onde a expression é necessário. (Contribuição de Sergey Miryanov em gh-129515.)

    >>> x = 1 if True else pass
Traceback (most recent call last):
  File "<string>", line 1
    x = 1 if True else pass
                       ^^^^
SyntaxError: expected expression after 'else', but statement is given

>>> x = continue if True else break
Traceback (most recent call last):
  File "<string>", line 1
    x = continue if True else break
        ^^^^^^^^
SyntaxError: expected expression before 'if', but statement is given

  • Quando strings fechadas incorretamente são detectadas, a mensagem de erro sugere que pode ser que a intenção era a string ser parte da string. (Contribuição de Pablo Galindo em gh-88535.)

    >>> "O objeto interessante "O objeto interessante" é muito importante"
Traceback (most recent call last):
SyntaxError: invalid syntax. Is this intended to be part of the string?

  • Quando strings têm prefixos incompatíveis, o erro agora mostra quais prefixos são incompatíveis. (Contribuição de Nikita Sobolev em gh-133197.)

    >>> ub'abc'
  File "<python-input-0>", line 1
    ub'abc'
    ^^
SyntaxError: 'u' and 'b' prefixes are incompatible

  • Mensagens de erro aprimoradas ao usar as com alvos incompatíveis em:

    • Importações: import ... as ...

    • Importações “from”: from ... import ... as ...

    • Manipuladores “except”: except ... as ...

    • Casos de correspondência de padrão: case ... as ...

    (Contribuição de Nikita Sobolev in gh-123539, gh-123562 e gh-123440.)

    >>> import ast as arr[0]
  File "<python-input-1>", line 1
    import ast as arr[0]
                  ^^^^^^
SyntaxError: cannot use subscript as import target

  • Mensagem de erro aprimorada ao tentar adicionar uma instância de um tipo não-hasheável a um dict ou set. (Contribuição de CF Bolz-Tereick e Victor Stinner em gh-132828.)

    >>> s = set()
>>> s.add({'pages': 12, 'grade': 'A'})
Traceback (most recent call last):
  File "<python-input-1>", line 1, in <module>
    s.add({'pages': 12, 'grade': 'A'})
    ~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: cannot use 'dict' as a set element (unhashable type: 'dict')
>>> d = {}
>>> l = [1, 2, 3]
>>> d[l] = 12
Traceback (most recent call last):
  File "<python-input-4>", line 1, in <module>
    d[l] = 12
    ~^^^
TypeError: cannot use 'list' as a dict key (unhashable type: 'list')

PEP 741: API C de configuração do Python

Adiciona uma PyInitConfig API C para configurar a inicialização do Python sem depender de estruturas C e a capacidade de fazer alterações compatíveis com ABI no futuro.

Conclui a API C PyConfig da PEP 587 adicionando PyInitConfig_AddModule() que pode ser usado para adicionar um módulo de extensão embutido; um recurso anteriormente chamado de “inittab”.

Adiciona as funções PyConfig_Get() e PyConfig_Set() para obter e definir a configuração de tempo de execução atual.

A “Configuração de Inicialização do Python” da PEP 587 unificou todas as maneiras de configurar a inicialização do Python. Esta PEP também unifica a configuração da pré-inicialização do Python e a inicialização do Python em uma única API. Além disso, esta PEP oferece apenas uma opção para incorporar o Python, em vez de ter duas opções, “Python” e “Isolated” (PEP 587), simplificando ainda mais a API.

A API PyConfig da PEP 587 de nível inferior permanece disponível para casos de uso com um nível intencionalmente mais alto de acoplamento aos detalhes de implementação do CPython (como emular a funcionalidade completa da CLI do CPython, incluindo seus mecanismos de configuração).

(Contribuição de Victor Stinner em gh-107954.)

Ver também

PEP 741.

Capacidades de introspecção assíncrona

Foi adicionada uma nova interface de linha de comando para inspecionar processos Python em execução usando tarefas assíncronas, disponível via:

python -m asyncio ps PID

Esta ferramenta inspeciona o ID do processo (PID) fornecido e exibe informações sobre as tarefas assíncronas em execução. Ela gera uma tabela de tarefas: uma lista simples de todas as tarefas, seus nomes, suas pilhas de corrotinas e quais tarefas as aguardam.

python -m asyncio pstree PID

Esta ferramenta busca as mesmas informações, mas renderiza uma árvore de chamadas assíncrona visual, mostrando os relacionamentos das corrotinas em um formato hierárquico. Este comando é particularmente útil para depurar programas assíncronos de longa execução ou travados. Ele pode ajudar os desenvolvedores a identificar rapidamente onde um programa está bloqueado, quais tarefas estão pendentes e como as corrotinas estão encadeadas.

Por exemplo, dado este código:

import asyncio

async def play(track):
    await asyncio.sleep(5)
    print(f"🎵 Finished: {track}")

async def album(name, tracks):
    async with asyncio.TaskGroup() as tg:
        for track in tracks:
            tg.create_task(play(track), name=track)

async def main():
    async with asyncio.TaskGroup() as tg:
        tg.create_task(
          album("Sundowning", ["TNDNBTG", "Levitate"]), name="Sundowning")
        tg.create_task(
          album("TMBTE", ["DYWTYLM", "Aqua Regia"]), name="TMBTE")

if __name__ == "__main__":
    asyncio.run(main())

Executar a nova ferramenta no processo em execução produzirá uma tabela como esta:

python -m asyncio ps 12345

tid        task id              task name            coroutine stack                                    awaiter chain                                      awaiter name    awaiter id
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1935500    0x7fc930c18050       Task-1               TaskGroup._aexit -> TaskGroup.__aexit__ -> main                                                                       0x0
1935500    0x7fc930c18230       Sundowning           TaskGroup._aexit -> TaskGroup.__aexit__ -> album   TaskGroup._aexit -> TaskGroup.__aexit__ -> main    Task-1          0x7fc930c18050
1935500    0x7fc93173fa50       TMBTE                TaskGroup._aexit -> TaskGroup.__aexit__ -> album   TaskGroup._aexit -> TaskGroup.__aexit__ -> main    Task-1          0x7fc930c18050
1935500    0x7fc93173fdf0       TNDNBTG              sleep -> play                                      TaskGroup._aexit -> TaskGroup.__aexit__ -> album   Sundowning      0x7fc930c18230
1935500    0x7fc930d32510       Levitate             sleep -> play                                      TaskGroup._aexit -> TaskGroup.__aexit__ -> album   Sundowning      0x7fc930c18230
1935500    0x7fc930d32890       DYWTYLM              sleep -> play                                      TaskGroup._aexit -> TaskGroup.__aexit__ -> album   TMBTE           0x7fc93173fa50
1935500    0x7fc93161ec30       Aqua Regia           sleep -> play                                      TaskGroup._aexit -> TaskGroup.__aexit__ -> album   TMBTE           0x7fc93173fa50

ou uma árvore como esta:

python -m asyncio pstree 12345

└── (T) Task-1
    └──  main example.py:13
        └──  TaskGroup.__aexit__ Lib/asyncio/taskgroups.py:72
            └──  TaskGroup._aexit Lib/asyncio/taskgroups.py:121
                ├── (T) Sundowning
                │   └──  album example.py:8
                │       └──  TaskGroup.__aexit__ Lib/asyncio/taskgroups.py:72
                │           └──  TaskGroup._aexit Lib/asyncio/taskgroups.py:121
                │               ├── (T) TNDNBTG
                │               │   └──  play example.py:4
                │               │       └──  sleep Lib/asyncio/tasks.py:702
                │               └── (T) Levitate
                │                   └──  play example.py:4
                │                       └──  sleep Lib/asyncio/tasks.py:702
                └── (T) TMBTE
                    └──  album example.py:8
                        └──  TaskGroup.__aexit__ Lib/asyncio/taskgroups.py:72
                            └──  TaskGroup._aexit Lib/asyncio/taskgroups.py:121
                                ├── (T) DYWTYLM
                                │   └──  play example.py:4
                                │       └──  sleep Lib/asyncio/tasks.py:702
                                └── (T) Aqua Regia
                                    └──  play example.py:4
                                        └──  sleep Lib/asyncio/tasks.py:702

Se um ciclo for detectado no grafo async await (o que pode indicar um problema de programação), a ferramenta levanta um erro e lista os caminhos de ciclo que impedem a construção da árvore:

python -m asyncio pstree 12345

ERROR: await-graph contains cycles - cannot print a tree!

cycle: Task-2 → Task-3 → Task-2

(Contribuição de Pablo Galindo, Łukasz Langa, Yury Selivanov e Marta Gomez Macias em gh-91048.)

Um novo tipo de interpretador

Um novo tipo de interpretador foi adicionado ao CPython. Ele utiliza chamadas de cauda entre pequenas funções C que implementam opcodes Python individuais, em vez de uma única instrução case C extensa. Para alguns compiladores mais recentes, este interpretador oferece desempenho significativamente melhor. Dados preliminares em nossas máquinas sugerem um código Python até 30% mais rápido e uma média geométrica de 3 a 5% mais rápido no pyperformance, dependendo da plataforma e da arquitetura. A linha de base é o Python 3.14, construído com o Clang 19 sem este novo interpretador.

Atualmente, este interpretador funciona apenas com o Clang 19 e versões mais recentes em arquiteturas x86-64 e AArch64. No entanto, esperamos que uma versão futura do GCC também ofereça suporte a ele.

Este recurso é opcional por enquanto. Recomendamos fortemente habilitar a otimização guiada por perfil com o novo interpretador, pois é a única configuração que testamos e podemos validar seu desempenho aprimorado. Para mais informações sobre como construir Python, consulte --with-tail-call-interp.

Nota

Isso não deve ser confundido com a otimização de chamada de cauda de funções Python, que atualmente não está implementada no CPython.

Este novo tipo de interpretador é um detalhe de implementação interna do interpretador CPython. Ele não altera em nada o comportamento visível dos programas Python. Pode melhorar o desempenho deles, mas não altera nada mais.

Atenção

Esta seção relatou anteriormente um aumento de velocidade médio geométrico de 9 a 15%. Desde então, esse número foi cuidadosamente revisado reduzindo para 3 a 5%. Embora esperemos que os resultados de desempenho sejam melhores do que os relatados, nossas estimativas são mais conservadoras devido a um bug do compilador encontrado no Clang/LLVM 19, que faz com que o interpretador normal seja mais lento. Não tínhamos conhecimento desse bug, resultando em resultados imprecisos. Pedimos sinceras desculpas por comunicar resultados que eram precisos apenas para o LLVM v19.1.x e v20.1.0. Neste meio-tempo, o bug foi corrigido no LLVM v20.1.1 e para o próximo v21.1, mas permanecerá sem correção para o LLVM v19.1.x e v20.1.0. Portanto, quaisquer benchmarks com essas versões do LLVM podem produzir números imprecisos. (Agradecimentos a Nelson Elhage por trazer isso à tona.)

(Contribuição de Ken Jin em gh-128563, com ideias sobre como implementar isso em CPython por Mark Shannon, Garrett Gu, Haoran Xu e Josh Haberman.)

Modo de threads livres

O modo de threads livres (PEP 703), adicionado inicialmente na versão 3.13, foi significativamente aprimorado. A implementação descrita no PEP 703 foi concluída, incluindo alterações na API C, e soluções temporárias no interpretador foram substituídas por soluções mais permanentes. O interpretador adaptativo especializado (PEP 659) agora está habilitado no modo de threads livres, o que, juntamente com muitas outras otimizações, melhora significativamente seu desempenho. A perda de desempenho em código de thread única no modo de threads livres agora é de aproximadamente 5 a 10%, dependendo da plataforma e do compilador C utilizados.

Este trabalho foi realizado por muitos colaboradores: Sam Gross, Matt Page, Neil Schemenauer, Thomas Wouters, Donghee Na, Kirill Podoprigora, Ken Jin, Itamar Oren, Brett Simmers, Dino Viehland, Nathan Goldbaum, Ralf Gommers, Lysandros Nikolaou, Kumar Aditya, Edgar Margffoy e muitos outros.

Alguns desses colaboradores são empregados da Meta, que continuou a fornecer recursos de engenharia significativos para dar suporte a este projeto.

A partir da versão 3.14, ao compilar módulos de extensão para a construção do CPython com threads livres no Windows, a variável de pré-processador Py_GIL_DISABLED agora precisa ser especificada pelo backend de construção, pois não será mais determinada automaticamente pelo compilador C. Para um interpretador em execução, a configuração usada em tempo de compilação pode ser encontrada usando sysconfig.get_config_var().

Um novo sinalizador foi adicionado, context_aware_warnings. Este sinalizador assume como padrão true para a construção com threads livres e false para a construção com GIL habilitada. Se o sinalizador for true, o gerenciador de contexto warnings.catch_warnings usa uma variável de contexto para filtros de aviso. Isso faz com que o gerenciador de contexto se comporte de forma previsível quando usado com múltiplas threads ou tarefas assíncronas.

Um novo sinalizador foi adicionado, thread_inherit_context. Esta flag assume como padrão true para a construção com threads livres e false para a construção com GIL habilitada. Se o sinalizador for true, as threads criadas com threading.Thread iniciam com uma cópia de Context() do chamador de start(). Mais significativamente, isso faz com que o contexto de filtragem de avisos estabelecido por catch_warnings seja “herdado” por threads (ou tarefas assíncronas) iniciadas nesse contexto. Também afeta outros módulos que usam variáveis de contexto, como o gerenciador de contexto decimal.

Realce de sintaxe no PyREPL

O console interativo padrão agora realça a sintaxe do Python à medida que você digita. O recurso está ativado por padrão, a menos que a variável de ambiente PYTHON_BASIC_REPL esteja configurado ou que qualquer variável de ambiente de desativação de cor seja usada. Consulte Controlando cores para obter detalhes.

O tema de cores padrão para realce de sintaxe busca um bom contraste e usa exclusivamente os códigos de cores ANSI padrão VGA de 4 bits para obter a máxima compatibilidade. O tema pode ser personalizado com o uso de uma API experimental _colorize.set_theme(). Isso pode ser chamado interativamente, bem como no script PYTHONSTARTUP.

(Contribuição de Łukasz Langa em gh-131507.)

Versões binárias para o compilador experimental just-in-time

Os binários oficiais de lançamento para macOS e Windows agora incluem um compilador JIT (just-in-time) experimental. Embora não seja recomendado para uso em produção, ele pode ser testado definindo PYTHON_JIT=1 como uma variável de ambiente. Construções de código-fonte downstream e redistribuidores podem usar a opção de configuração --enable-experimental-jit=yes-off para obter um comportamento semelhante.

O JIT está em estágio inicial e ainda em desenvolvimento ativo. Portanto, o impacto típico de sua ativação no desempenho pode variar de 10% mais lento a 20% mais rápido, dependendo da carga de trabalho. Para auxiliar nos testes e na avaliação, um conjunto de funções de introspecção foi fornecido no espaço de nomes sys._jit. sys._jit.is_available() pode ser usado para determinar se o executável atual oferece suporte a compilação JIT, enquanto sys._jit.is_enabled() pode ser usado para informar se a compilação JIT foi ativada para o processo atual.

Atualmente, a funcionalidade ausente mais significativa é que depuradores e profilers nativos, como gdb e perf, não conseguem desenrolar quadros JIT (depuradores e profilers Python, como pdb ou profile, continuam funcionando sem modificações). Construções com threads livres não oferecem suporte a compilação JIT.

Por favor, relate quaisquer bugs ou grandes regressões de desempenho que você encontrar!

Ver também

PEP 744

Controle de avisos seguros simultâneos

O gerenciador de contexto warnings.catch_warnings agora usará opcionalmente uma variável de contexto para filtros de aviso. Isso é habilitado definindo o sinalizador context_aware_warnings, seja com a opção de linha de comando -X ou com uma variável de ambiente. Isso fornece controle previsível de avisos ao usar catch_warnings combinado com múltiplas threads ou tarefas assíncronas. O sinalizador padrão é true para a construção com threads livres e false para a construção com GIL habilitada.

(Contribuição de Neil Schemenauer e Kumar Aditya em gh-130010.)

Coleta de lixo incremental

O coletor de lixo cíclico agora é incremental. Isso significa que os tempos máximos de pausa são reduzidos em uma ordem de magnitude ou mais para heaps maiores.

Agora existem apenas duas gerações: jovem e velha. Quando gc.collect() não é chamado diretamente, o coletor de lixo é invocado com um pouco menos de frequência. Quando invocado, ele coleta a geração jovem e um incremento da geração antiga, em vez de coletar uma ou mais gerações.

O comportamento de gc.collect() muda ligeiramente:

  • gc.collect(1): Executa um incremento da coleta de lixo, em vez de coletar a geração 1.

  • Outras chamadas para gc.collect() não foram alteradas.

(Contribuição de Mark Shannon em gh-108362.)

Suporte a plataforma

Outras mudanças de linguagem

  • O shell padrão interativo agora oferece suporte ao preenchimento automático de importação. Isso significa que digitar import foo e pressionar <tab> sugerirá módulos que começam com foo. Da mesma forma, digitar from foo import b sugerirá submódulos de foo que começam com b. Observe que o preenchimento automático de atributos de módulo não é suportado atualmente. (Contribuição de Tomas Roun em gh-69605.)

  • O map() embutido agora possui um sinalizador somente-nomeado opcional strict, como zip(), para verificar se todos os iteráveis têm o mesmo comprimento. (Contribuição de Wannes Boeykens em gh-119793.)

  • O uso incorreto de await e compreensões assíncronas agora é detectado mesmo que o código seja otimizado pela opção de linha de comando -O. Por exemplo, python -O -c 'assert await 1' agora produz um SyntaxError. (Contribuição de Jelle Zijlstra em gh-121637.)

  • Escritas em __debug__ agora são detectadas mesmo que o código seja otimizado pela opção de linha de comando -O. Por exemplo, python -O -c 'assert (__debug__ := 1)' agora produz um SyntaxError. (Contribuição de Irit Katriel em gh-122245.)

  • Adiciona os métodos de classe float.from_number() e complex.from_number() para converter um número para o tipo float ou complex, respectivamente. Eles levantam um erro se o argumento for uma string. (Contribuição de Serhiy Storchaka em gh-84978.)

  • Implementa regras aritméticas de modo misto combinando números reais e complexos, conforme especificado pelos padrões C desde C99. (Contribuição de Sergey B Kirpichev em gh-69639.)

  • Todas as páginas de código do Windows agora são suportadas como codecs “cpXXX” no Windows. (Contribuição de Serhiy Storchaka em gh-123803.)

  • Os objetos super agora são serializáveis com pickle e copiáveis. (Contribuição de Serhiy Storchaka em gh-125767.)

  • O tipo memoryview agora oferece suporte a subscrição, tornando-o um tipo genérico. (Contribuição de Brian Schubert em gh-126012.)

  • Suporte para sublinhado e vírgula como separadores de milhares na parte fracionária para tipos de apresentação de ponto flutuante do novo estilo de formatação de string (com format() ou Literais de strings formatadas). (Contribuição de Sergey B Kirpichev em gh-87790.)

  • Os métodos bytes.fromhex() e bytearray.fromhex() agora aceitam objetos ASCII bytes e similares. (Contribuição de Daniel Pope em gh-129349.)

  • Suporte a \z como sinônimo de \Z em expressões regulares. É interpretado sem ambiguidade em muitos outros mecanismos de expressão regular, ao contrário de \Z, que tem um comportamento ligeiramente diferente. (Contribuição de Serhiy Storchaka em gh-133306.)

  • \B em expressão regular agora corresponde a uma string de entrada vazia. Agora é sempre o oposto de \b. (Contribuição de Serhiy Storchaka em gh-124130.)

  • Aplicações iOS e macOS agora podem ser configurados para redirecionar o conteúdo stdout e stderr para o log do sistema. (Contribuição de Russell Keith-Magee em gh-127592.)

  • O ambiente de teste do iOS agora pode transmitir a saída do teste enquanto ele está em execução. O ambiente de teste também pode ser usado para executar o conjunto de testes de outros projetos além do CPython. (Contribuição de Russell Keith-Magee em gh-127592.)

  • pow() de três argumentos agora tenta chamar __rpow__() se necessário. Anteriormente, ele só era chamado em pow() de dois argumentos e no operador binário de potência. (Contribuição de Serhiy Storchaka em gh-130104.)

  • Adiciona uma implementação embutido para HMAC (RFC 2104) usando código formalmente verificado do projeto HACL*. Esta implementação é usada como fallback quando a implementação OpenSSL do HMAC não está disponível. (Contribuição de Bénédikt Tran em gh-99108.)

  • O sinalizador de tempo de importação agora pode rastrear módulos já carregados (‘em cache’), por meio da nova opção -X importtime=2. Quando um módulo desse tipo é importado, os tempos self e cumulative são substituídos pela string cached. Valores acima de 2 para -X importtime agora são reservados para uso futuro. (Contribuição de Noah Kim e Adam Turner em gh-118655.)

  • Ao criar uma subclasse de um tipo C puro, os slots C para o novo tipo não são mais substituídos por uma versão encapsulada na criação da classe, caso não sejam explicitamente substituídos na subclasse. (Contribuição de Tomasz Pytel em gh-132329.)

  • A opção de linha de comando -c agora recua automaticamente seu argumento de código antes da execução. O comportamento de dedentação automática espelha textwrap.dedent(). (Contribuição de Jon Crall e Steven Sun em gh-103998.)

  • Melhoria na mensagem de erro quando um objeto que oferece suporte ao protocolo do gerenciador de contexto síncrono é inserido usando async with em vez de with. E vice-versa com o protocolo do gerenciador de contexto assíncrono. (Contribuição de Bénédikt Tran em gh-128398.)

  • -J não é mais um sinalizador reservado para Jython e agora não tem nenhum significado especial. (Contribuição de Adam Turner em gh-133336.)

  • O int() embutido não delega mais para __trunc__(). Classes que desejam oferecer suporte a conversão para int() devem implementar __int__() ou __index__(). (Contribuição de Mark Dickinson em gh-119743.)

  • Usa NotImplemented em um contexto booleano agora levantará TypeError. Isso levanta DeprecationWarning desde o Python 3.9. (Contribuição de Jelle Zijlstra em gh-118767.)

PEP 765: não permitir return/break/continue que saia de um bloco finally

O compilador emite uma SyntaxWarning quando uma instrução return, break ou continue aparece onde sai de um bloco finally. Essa alteração é especificada na PEP 765.

Novos módulos

Módulos melhorados

argparse

  • O valor padrão do nome do programa para argparse.ArgumentParser agora reflete a maneira como o interpretador Python foi instruído a encontrar o código do módulo __main__. (Contribuição de Serhiy Storchaka e Alyssa Coghlan em gh-66436.)

  • Foi introduzido o parâmetro opcional suggest_on_error em argparse.ArgumentParser, permitindo sugestões para escolhas de argumentos e nomes de subanalisadores caso sejam digitados incorretamente pelo usuário. (Contribuição de Savannah Ostrowski em gh-124456.)

  • Habilita a cor do texto de ajuda, que pode ser desabilitada com o parâmetro opcional color em argparse.ArgumentParser. Isso também pode ser controlado por variáveis de ambiente. (Contribuição de Hugo van Kemenade em gh-130645.)

ast

  • Adiciona ast.compare() para comparar dois ASTs. (Contribuição de Batuhan Taskaya e Jeremy Hylton em gh-60191.)

  • Adiciona suporte para copy.replace() para nós AST. (Contribuição de Bénédikt Tran em gh-121141.)

  • Docstrings agora são removidas de um AST otimizado no nível de otimização 2. (Contribuição de Irit Katriel em gh-123958.)

  • A saída repr() para nós AST agora inclui mais informações. (Contribuição de Tomas Roun em gh-116022.)

  • ast.parse(), quando chamado com um AST como entrada, agora sempre verifica se o tipo de nó raiz é apropriado. (Contribuição de Irit Katriel em gh-130139.)

  • Adiciona as novas opções --feature-version, --optimize e --show-empty à interface de linha de comando. (Contribuição de Semyon Moroz em gh-133367.)

asyncio

  • A função e os métodos denominados create_task() agora aceitam uma lista arbitrária de argumentos nomeados. Todos os argumentos nomeados são passados para o construtor Task ou para a fábrica de tarefas personalizada. (Consulte set_task_factory() para obter detalhes.) Os argumentos nomeados name e context não são mais especiais; o nome agora deve ser definido usando o argumento nomeados name da fábrica, e context pode ser None.

    Isso afeta as seguintes funções e métodos: asyncio.create_task(), asyncio.loop.create_task(), asyncio.TaskGroup.create_task(). (Contribuição de Thomas Grainger em gh-128307.)

  • Há duas novas funções utilitárias para introspecção e impressão do gráfico de chamadas de um programa: capture_call_graph() e print_call_graph(). (Contribuição de Yury Selivanov, Pablo Galindo Salgado e Łukasz Langa em gh-91048.)

calendar

concurrent.futures

  • Adiciona InterpreterPoolExecutor, que expõe “subinterpretadores” (vários interpretadores Python no mesmo processo) ao código Python. Isso é separado da API proposta na PEP 734. (Contribuição de Eric Snow em gh-124548.)

configparser

contextvars

  • Adiciona suporte ao protocolo do gerenciador de contexto por contextvars.Token. (Contribuição de Andrew Svetlov em gh-129889.)

ctypes

curses

datetime

decimal

difflib

  • Páginas de comparação com alterações destacadas geradas pela classe difflib.HtmlDiff agora oferecem suporte ao modo escuro. (Contribuição de Jiahao Li em gh-129939.)

dis

errno

faulthandler

fnmatch

fractions

  • Adiciona suporte para converter qualquer objeto que tenha o método as_integer_ratio() em uma Fraction. (Contribuição de Serhiy Storchaka em gh-82017.)

  • Adiciona o construtor alternativo Fraction.from_number() para Fraction. (Contribuição de Serhiy Storchaka in gh-121797.)

functools

getopt

  • Adiciona suporte para opções com argumento opcional. (Contribuição de Serhiy Storchaka em gh-126374.)

  • Adiciona suporte para retornar opções misturadas e argumentos não-opcionais em ordem. (Contribuição de Serhiy Storchaka em gh-126390.)

getpass

  • Suporte a feedback do teclado pelo getpass.getpass() por meio do argumento opcional somente-nomeado echo_char. Espaços reservados para caracteres são renderizados sempre que um caractere é inserido e removidos quando um caractere é excluído. (Contribuição de Semyon Moroz em gh-77065.)

graphlib

heapq

hmac

  • Adiciona uma implementação embutida para HMAC (RFC 2104) usando o código formalmente verificado do projeto HACL*. (Contribuição de Bénédikt Tran em gh-99108.)

http

  • As páginas de erro e listas de diretórios geradas pelo módulo http.server permitem que o navegador aplique seu modo escuro padrão. (Contribuição de Yorik Hansen em gh-123430.)

  • O módulo http.server agora provê suporte para HTTPS usando a classe http.server.HTTPSServer. Essa funcionalidade é exposta pela interface de linha de comando (python -m http.server) por meio das seguintes opções:

    • --tls-cert <path>: caminho para o arquivo de certificado TLS.

    • --tls-key <path>: caminho opcional para o arquivo de chave privada.

    • --tls-password-file <path>: caminho opcional para o arquivo de senha da chave privada.

    (Contribuição de Semyon Moroz em gh-85162.)

imaplib

  • Adiciona o método IMAP4.idle(), que implementa o comando IDLE do IMAP4 conforme definido em RFC 2177. (Contribuição de Forest em gh-55454.)

inspect

io

json

linecache

logging.handlers

math

  • Adicionadas mensagens de erro mais detalhadas para erros de domínio no módulo. (Contribuição de Charlie Zhao e Sergey B Kirpichev em gh-101410.)

mimetypes

  • Documenta a linha de comando para mimetypes. Agora, ele é encerrado com 1 em caso de falha, em vez de 0, e 2 em caso de parâmetros de linha de comando incorretos, em vez de 1. Além disso, os erros são enviados para stderr em vez de stdout, e seu texto é mais conciso. (Contribuição de Oleg Iarygin e Hugo van Kemenade em gh-93096.)

  • Adiciona tipos MIME de RFC 8081 e da MS para fontes:

    • Embedded OpenType: application/vnd.ms-fontobject

    • OpenType Layout (OTF) font/otf

    • TrueType: font/ttf

    • WOFF 1.0 font/woff

    • WOFF 2.0 font/woff2

    (Contribuição de Sahil Prajapati e Hugo van Kemenade em gh-84852.)

  • Adicione os tipos MIME de RFC 9559 para estruturas de contêiner de dados audiovisuais Matroska, contendo:

    • áudio com nenhum vídeo: audio/matroska (.mka)

    • vídeo: video/matroska (.mkv)

    • vídeo estereoscópico: video/matroska-3d (.mk3d)

    (Contribuição de Hugo van Kemenade em gh-89416.)

  • Adiciona tipos MIME para imagens com RFCs:

    • RFC 1494: CCITT Group 3 (.g3)

    • RFC 3362: Real-time Facsimile, T.38 (.t38)

    • RFC 3745: JPEG 2000 (.jp2), extensão (.jpx) e composto (.jpm)

    • RFC 3950: Tag Image File Format Fax eXtended, TIFF-FX (.tfx)

    • RFC 4047: Flexible Image Transport System (.fits)

    • RFC 7903: Enhanced Metafile (.emf) and Windows Metafile (.wmf)

    (Contribuição de Hugo van Kemenade em gh-85957.)

  • Mais alterações de tipo MIME:

    • RFC 2361: altera o tipo de .avi para video/vnd.avi e de .wav para audio/vnd.wave

    • RFC 4337: adiciona MPEG-4 audio/mp4 (.m4a)

    • RFC 5334: adiciona mídia Ogg (.oga, .ogg e .ogx)

    • RFC 6713: adiciona gzip aplication/gzip (.gz)

    • RFC 9639: adiciona FLAC audio/flac (.flac)

    • Adiciona 7z aplication/x-7z-compressed (.7z)

    • Adiciona Android Package application/vnd.android.package-archive (.apk) quando não for rigoroso

    • Adiciona deb application/x-debian-package (.deb)

    • Adiciona glTF binário model/gltf-binary (.glb)

    • Adiciona glTF JSON/ASCII model/gltf+json (.gltf)

    • Adiciona M4V video/x-m4v (.m4v)

    • Adiciona PHP application/x-httpd-php (.php)

    • Adiciona RAR application/vnd.rar (.rar)

    • Adiciona RPM application/x-rpm (.rpm)

    • Adiciona STL model/stl (.stl)

    • Adiciona Windows Media Video video/x-ms-wmv (.wmv)

    • De facto: adiciona WebM audio/webm (.weba)

    • ECMA-376: adiciona tipos .docx, .pptx e .xlsx

    • OASIS: adiciona tipos OpenDocument .odg, .odp, .ods e .odt

    • W3C: adiciona EPUB application/epub+zip (.epub)

    (Contribuição de Hugo van Kemenade em gh-129965.)

  • Adiciona RFC 9512 application/yaml tipo MIME para arquivos YAML (.yaml and .yml). (Contribuição de Sasha “Nelie” Chernykh e Hugo van Kemenade in gh-132056.)

multiprocessing

operador

  • Foram adicionadas duas novas funções: operator.is_none() e operator.is_not_none(). De modo que operator.is_none(obj) equivale a obj is None e operator.is_not_none(obj) equivale a obj is not None . (Contribuição de Raymond Hettinger e Nico Mexis em gh-115808.)

os

os.path

pathlib

  • Adiciona métodos a pathlib.Path para copiar ou mover arquivos e diretórios recursivamente:

    • copy() copia um arquivo ou árvore de diretório para um destino.

    • copy_into() copia para um diretório de destino.

    • move() move um arquivo ou árvore de diretórios para um destino.

    • move_into() move para um diretório de destino.

    (Contribuição de Barney Gale em gh-73991.)

  • Adiciona o atributo pathlib.Path.info, que armazena um objeto que implementa o protocolo pathlib.types.PathInfo (também novo). O objeto oferece suporte à consulta do tipo de arquivo e armazenamento em cache interno dos resultados de stat(). Objetos de caminho gerados por iterdir() são inicializados com informações do tipo de arquivo obtidas a partir da varredura do diretório pai. (Contribuição de Barney Gale em gh-125413.)

pdb

  • Pontos de interrupção codificados diretamente no código-fonte (breakpoint() e pdb.set_trace()) agora reutilizam a instância mais recente de Pdb que chama set_trace(), em vez de criar uma nova a cada vez. Como resultado, todos os dados específicos da instância, como display e commands, são preservados em todos os pontos de interrupção. (Contribuição de Tian Gao em gh-121450.)

  • Adiciona um novo argumento mode a pdb.Pdb. Desabilita o comando restart quando pdb estiver no modo inline. (Contribuição de Tian Gao em gh-123757.)

  • Um prompt de confirmação será exibido quando o usuário tentar sair do comando pdb no modo inline. y, Y, <Enter> ou EOF confirmarão o encerramento e chamarão sys.exit(), em vez de executar bdb.BdbQuit. (Contribuição de Tian Gao em gh-124704.)

  • Pontos de interrupção em linha como breakpoint() ou pdb.set_trace() sempre interromperão o programa ao chamar o quadro, ignorando o padrão skip (se houver). (Contribuição de Tian Gao em gh-130493.)

  • <tab> no início da linha na entrada multilinha pdb agora preencherá um recuo de 4 espaços, em vez de inserir um caractere \t. (Contribuição de Tian Gao em gh-130471.)

  • A indentar automática foi introduzida na entrada multilinha pdb. Ela mantém a indentação da última linha ou insere uma indentação de 4 espaços ao detectar um novo bloco de código. (Contribuição de Tian Gao em gh-133350.)

  • $_asynctask foi adicionado para acessar a tarefa asyncio atual, se aplicável. (Contribuição de Tian Gao em gh-124367.)

  • pdb.set_trace_async() foi adicionado para oferecer suporte à depuração de corrotinas assíncronas. Instruções await são suportadas com esta função. (Contribuição de Tian Gao em gh-132576.)

  • O código-fonte exibido em pdb terá a sintaxe realçada. Este recurso pode ser controlado usando os mesmos métodos do PyREPL, além do argumento colorize recém-adicionado de pdb.Pdb. (Contribuição de Tian Gao e Łukasz Langa em gh-133355.)

pickle

  • Define a versão do protocolo padrão no módulo pickle como 5. Para mais detalhes, consulte protocolos pickle.

  • Adiciona notas para erros de serialização do Pickle que permitam identificar a origem do erro. (Contribuição de Serhiy Storchaka em gh-122213.)

platform

pydoc

  • Anotações na saída de ajuda agora são exibidas em um formato mais próximo ao da fonte original. (Contribuição de Jelle Zijlstra em gh-101552.)

socket

  • Melhora e corrige o suporte para soquetes Bluetooth.

    • Corrige o suporte a soquetes Bluetooth no NetBSD e no DragonFly BSD. (Contribuição de Serhiy Storchaka em gh-132429.)

    • Corrige o suporte para BTPROTO_HCI no FreeBSD. (Contribuição de Victor Stinner em gh-111178.)

    • Adiciona suporte para BTPROTO_SCO no FreeBSD. (Contribuição de Serhiy Storchaka em gh-85302.)

    • Adiciona suporte para cid e bdaddr_type no endereço para BTPROTO_L2CAP no FreeBSD. (Contribuição de Serhiy Storchaka em gh-132429.)

    • Adiciona suporte para channel no endereço para BTPROTO_HCI no Linux. (Contribuição de Serhiy Storchaka em gh-70145.)

    • Aceita um inteiro como endereço para BTPROTO_HCI no Linux. (Contribuição de Serhiy Storchaka em gh-132099.)

    • Retorna cid em getsockname() para BTPROTO_L2CAP. (Contribuição de Serhiy Storchaka em gh-132429.)

    • Adiciona muitas novas constantes. (Contribuição de Serhiy Storchaka em gh-132734.)

ssl

  • Indica através de ssl.HAS_PHA se o módulo ssl oferece suporte a autenticação de cliente pós-handshake (PHA) TLSv1.3. (Contribuição de Will Childs-Klein em gh-128036.)

struct

  • Suporte aos tipos C float complex e double complex no módulo struct (formatando os caracteres 'F' e 'D', respectivamente). (Contribuição de Sergey B Kirpichev em gh-121249.)

symtable

sys

  • A função especial sys.getobjects(), anteriormente não documentada, que só existe em construções especializadas do Python, agora pode retornar objetos de outros interpretadores além daquele em que foi chamada.

  • Adiciona sys._is_immortal() para determinar se um objeto é imortal. (Contribuição de Peter Bierma em gh-128509.)

  • No FreeBSD, sys.platform não contém mais a versão principal. É sempre 'freebsd', em vez de 'freebsd13' ou 'freebsd14'.

  • Levanta DeprecationWarning para sys._clear_type_cache(). Esta função foi descontinuada no Python 3.13, mas não levantava um aviso em tempo de execução.

sys.monitoring

sysconfig

tarfile

threading

tkinter

  • Faz com que os métodos do widget tkinter after() e after_idle() aceitem argumentos passados como nomeados (Contribuição de Zhikang Yan em gh-126899.)

  • Adicionada a capacidade de especificar o nome para tkinter.OptionMenu e tkinter.ttk.OptionMenu. (Contribuição de Zhikang Yan em gh-130482.)

turtle

tipos

typing

  • types.UnionType e typing.Union agora são apelidos um do outro, o que significa que tanto as uniões no estilo antigo (criadas com Union[int, str]) quanto as uniões no estilo novo (int | str) agora criam instâncias do mesmo tipo em ambiente de execução. Isso unifica o comportamento entre as duas sintaxes, mas leva a algumas diferenças de comportamento que podem afetar os usuários que inspecionam tipos em ambiente de execução:

    • Ambas as sintaxes para criar uma união agora produzem a mesma representação de string em repr(). Por exemplo, repr(Union[int, str]) agora é "int | str" em vez de "typing.Union[int, str]".

    • Unions created using the old syntax are no longer cached. Previously, running Union[int, str] multiple times would return the same object (Union[int, str] is Union[int, str] would be True), but now it will return two different objects. Users should use == to compare unions for equality, not is. New-style unions have never been cached this way. This change could increase memory usage for some programs that use a large number of unions created by subscripting typing.Union. However, several factors offset this cost: unions used in annotations are no longer evaluated by default in Python 3.14 because of PEP 649; an instance of types.UnionType is itself much smaller than the object returned by Union[] was on prior Python versions; and removing the cache also saves some space. It is therefore unlikely that this change will cause a significant increase in memory usage for most users.

    • Previously, old-style unions were implemented using the private class typing._UnionGenericAlias. This class is no longer needed for the implementation, but it has been retained for backward compatibility, with removal scheduled for Python 3.17. Users should use documented introspection helpers like typing.get_origin() and typing.get_args() instead of relying on private implementation details.

    • It is now possible to use typing.Union itself in isinstance() checks. For example, isinstance(int | str, typing.Union) will return True; previously this raised TypeError.

    • The __args__ attribute of typing.Union objects is no longer writable.

    • It is no longer possible to set any attributes on typing.Union objects. This only ever worked for dunder attributes on previous versions, was never documented to work, and was subtly broken in many cases.

    (Contributed by Jelle Zijlstra in gh-105499.)

  • typing.TypeAliasType now supports star unpacking.

unicodedata

  • The Unicode database has been updated to Unicode 16.0.0.

unittest

urllib

  • Upgrade HTTP digest authentication algorithm for urllib.request by supporting SHA-256 digest authentication as specified in RFC 7616. (Contributed by Calvin Bui in gh-128193.)

  • Improve ergonomics and standards compliance when parsing and emitting file: URLs.

    In urllib.request.url2pathname():

    • Accept a complete URL when the new require_scheme argument is set to true.

    • Discard URL authority if it matches the local hostname.

    • Discard URL authority if it resolves to a local IP address when the new resolve_host argument is set to true.

    • Discard URL query and fragment components.

    • Raise URLError if a URL authority isn’t local, except on Windows where we return a UNC path as before.

    In urllib.request.pathname2url():

    • Return a complete URL when the new add_scheme argument is set to true.

    • Include an empty URL authority when a path begins with a slash. For example, the path /etc/hosts is converted to the URL ///etc/hosts.

    On Windows, drive letters are no longer converted to uppercase, and : characters not following a drive letter no longer cause an OSError exception to be raised.

    (Contributed by Barney Gale in gh-125866.)

uuid

webbrowser

  • Names in the BROWSER environment variable can now refer to already registered browsers for the webbrowser module, instead of always generating a new browser command.

    Isso torna possível definir BROWSER como o valor de um dos navegadores suportados no macOS.

zipfile

Otimizações

asyncio

  • Standard benchmark results have improved by 10-20%, following the implementation of a new per-thread double linked list for native tasks, also reducing memory usage. This enables external introspection tools such as python -m asyncio pstree to introspect the call graph of asyncio tasks running in all threads. (Contributed by Kumar Aditya in gh-107803.)

  • The module now has first class support for free-threading builds. This enables parallel execution of multiple event loops across different threads, scaling linearly with the number of threads. (Contributed by Kumar Aditya in gh-128002.)

base64

  • b16decode() is now up to six times faster. (Contributed by Bénédikt Tran, Chris Markiewicz, and Adam Turner in gh-118761.)

bdb

  • The basic debugger now has a sys.monitoring-based backend, which can be selected via the passing 'monitoring' to the Bdb class’s new backend parameter. (Contributed by Tian Gao in gh-124533.)

difflib

  • The IS_LINE_JUNK() function is now up to twice as fast. (Contributed by Adam Turner and Semyon Moroz in gh-130167.)

gc

  • The new incremental garbage collector means that maximum pause times are reduced by an order of magnitude or more for larger heaps.

    Because of this optimization, the meaning of the results of get_threshold() and set_threshold() have changed, along with get_count() and get_stats().

    • For backwards compatibility, get_threshold() continues to return a three-item tuple. The first value is the threshold for young collections, as before; the second value determines the rate at which the old collection is scanned (the default is 10, and higher values mean that the old collection is scanned more slowly). The third value is now meaningless and is always zero.

    • set_threshold() now ignores any items after the second.

    • get_count() and get_stats() continue to return the same format of results. The only difference is that instead of the results referring to the young, aging and old generations, the results refer to the young generation and the aging and collecting spaces of the old generation.

    In summary, code that attempted to manipulate the behavior of the cycle GC may not work exactly as intended, but it is very unlikely to be harmful. All other code will work just fine.

    (Contribuição de Mark Shannon em gh-108362.)

io

  • Opening and reading files now executes fewer system calls. Reading a small operating system cached file in full is up to 15% faster. (Contributed by Cody Maloney and Victor Stinner in gh-120754 and gh-90102.)

pathlib

  • Path.read_bytes now uses unbuffered mode to open files, which is between 9% and 17% faster to read in full. (Contributed by Cody Maloney in gh-120754.)

pdb

uuid

  • uuid3() and uuid5() are now both roughly 40% faster for 16-byte names and 20% faster for 1024-byte names. Performance for longer names remains unchanged. (Contributed by Bénédikt Tran in gh-128150.)

  • uuid4() is now c. 30% faster. (Contributed by Bénédikt Tran in gh-128150.)

zlib

  • On Windows, zlib-ng is now used as the implementation of the zlib module in the default binaries. There are no known incompatibilities between zlib-ng and the previously-used zlib implementation. This should result in better performance at all compression levels.

    It is worth noting that zlib.Z_BEST_SPEED (1) may result in significantly less compression than the previous implementation, whilst also significantly reducing the time taken to compress.

    (Contributed by Steve Dower in gh-91349.)

Removidos

argparse

  • Remove the type, choices, and metavar parameters of BooleanOptionalAction. These have been deprecated since Python 3.12. (Contributed by Nikita Sobolev in gh-118805.)

  • Calling add_argument_group() on an argument group now raises a ValueError. Similarly, add_argument_group() or add_mutually_exclusive_group() on a mutually exclusive group now both raise ValueErrors. This ‘nesting’ was never supported, often failed to work correctly, and was unintentionally exposed through inheritance. This functionality has been deprecated since Python 3.11. (Contributed by Savannah Ostrowski in gh-127186.)

ast

  • Remove the following classes, which have been deprecated aliases of Constant since Python 3.8 and have emitted deprecation warnings since Python 3.12:

    • Bytes

    • Ellipsis

    • NameConstant

    • Num

    • Str

    As a consequence of these removals, user-defined visit_Num, visit_Str, visit_Bytes, visit_NameConstant and visit_Ellipsis methods on custom NodeVisitor subclasses will no longer be called when the NodeVisitor subclass is visiting an AST. Define a visit_Constant method instead.

    (Contributed by Alex Waygood in gh-119562.)

  • Remove the following deprecated properties on ast.Constant, which were present for compatibility with the now-removed AST classes:

    • Constant.n

    • Constant.s

    Use Constant.value instead. (Contributed by Alex Waygood in gh-119562.)

asyncio

  • Remove the following classes, methods, and functions, which have been deprecated since Python 3.12:

    • AbstractChildWatcher

    • FastChildWatcher

    • MultiLoopChildWatcher

    • PidfdChildWatcher

    • SafeChildWatcher

    • ThreadedChildWatcher

    • AbstractEventLoopPolicy.get_child_watcher()

    • AbstractEventLoopPolicy.set_child_watcher()

    • get_child_watcher()

    • set_child_watcher()

    (Contributed by Kumar Aditya in gh-120804.)

  • asyncio.get_event_loop() now raises a RuntimeError if there is no current event loop, and no longer implicitly creates an event loop.

    (Contributed by Kumar Aditya in gh-126353.)

    There’s a few patterns that use asyncio.get_event_loop(), most of them can be replaced with asyncio.run().

    If you’re running an async function, simply use asyncio.run().

    Before:

    async def main():
    ...


loop = asyncio.get_event_loop()
try:
    loop.run_until_complete(main())
finally:
    loop.close()

    After:

    async def main():
    ...

asyncio.run(main())

    If you need to start something, for example, a server listening on a socket and then run forever, use asyncio.run() and an asyncio.Event.

    Before:

    def start_server(loop): ...

loop = asyncio.get_event_loop()
try:
    start_server(loop)
    loop.run_forever()
finally:
    loop.close()

    After:

    def start_server(loop): ...

async def main():
    start_server(asyncio.get_running_loop())
    await asyncio.Event().wait()

asyncio.run(main())

    If you need to run something in an event loop, then run some blocking code around it, use asyncio.Runner.

    Before:

    async def operation_one(): ...
def blocking_code(): ...
async def operation_two(): ...

loop = asyncio.get_event_loop()
try:
    loop.run_until_complete(operation_one())
    blocking_code()
    loop.run_until_complete(operation_two())
finally:
    loop.close()

    After:

    async def operation_one(): ...
def blocking_code(): ...
async def operation_two(): ...

with asyncio.Runner() as runner:
    runner.run(operation_one())
    blocking_code()
    runner.run(operation_two())

collections.abc

  • Remove ByteString, which has been deprecated since Python 3.12. (Contributed by Nikita Sobolev in gh-118803.)

email

  • Remove email.utils.localtime()’s isdst parameter, which was deprecated in and has been ignored since Python 3.12. (Contributed by Hugo van Kemenade in gh-118798.)

importlib.abc

itertools

  • Remove support for copy, deepcopy, and pickle operations from itertools iterators. These have emitted a DeprecationWarning since Python 3.12. (Contributed by Raymond Hettinger in gh-101588.)

pathlib

  • Remove support for passing additional keyword arguments to Path. In previous versions, any such arguments are ignored. (Contributed by Barney Gale in gh-74033.)

  • Remove support for passing additional positional arguments to PurePath.relative_to() and is_relative_to(). In previous versions, any such arguments are joined onto other. (Contributed by Barney Gale in gh-78707.)

pkgutil

  • Remove the get_loader() and find_loader() functions, which have been deprecated since Python 3.12. (Contributed by Bénédikt Tran in gh-97850.)

pty

  • Remove the master_open() and slave_open() functions, which have been deprecated since Python 3.12. Use pty.openpty() instead. (Contributed by Nikita Sobolev in gh-118824.)

sqlite3

typing

  • Remove ByteString, which has been deprecated since Python 3.12. (Contributed by Nikita Sobolev in gh-118803.)

urllib

  • Remove the Quoter class from urllib.parse, which has been deprecated since Python 3.11. (Contributed by Nikita Sobolev in gh-118827.)

  • Remove the URLopener and FancyURLopener classes from urllib.request, which have been deprecated since Python 3.3.

    myopener.open() can be replaced with urlopen(). myopener.retrieve() can be replaced with urlretrieve(). Customisations to the opener classes can be replaced by passing customized handlers to build_opener(). (Contributed by Barney Gale in gh-84850.)

Descontinuados

Remoção pendente no Python 3.15

  • O sistema de importação:

    • A definição de __cached__ em um módulo enquanto falha na definição de __spec__.cached está descontinuado. No Python 3.15, __cached__ deixará de ser definido ou levado em consideração pelo sistema de importação ou pela biblioteca padrão. (gh-97879)

    • A definição de __package__ em um módulo enquanto falha na definição de __spec__.parent está descontinuado. No Python 3.15, __package__ deixará de ser definido ou levado em consideração pelo sistema de importação ou pela biblioteca padrão. (gh-97879)

  • ctypes:

    • A função não documentada ctypes.SetPointerType() foi descontinuada desde o Python 3.13.

  • http.server:

    • A classe obsoleta e raramente usada CGIHTTPRequestHandler foi descontinuada desde o Python 3.13. Não existe substituição direta. Qualquer coisa é melhor que CGI para fazer a interface de um servidor web com um manipulador de requisição.

    • O sinalizador --cgi para a interface de linha de comando python -m http.server foi descontinuado desde o Python 3.13.

  • importlib:

    • Método load_module(): use exec_module().

  • locale:

  • pathlib:

  • platform:

    • java_ver() foi descontinuada desde o Python 3.13. Esta função é útil apenas para suporte Jython, tem uma API confusa e é amplamente não testada.

  • sysconfig:

  • threading:

    • RLock() não aceitará argumentos no Python 3.15. A passagem quaisquer argumentos foi descontinuada desde o Python 3.14, pois a versão Python não permite nenhum argumento, mas a versão C permite qualquer número de argumentos posicionais ou nomeados, ignorando todos os argumentos.

  • types:

  • typing:

    • A não-documentada sintaxe de argumento nomeado para criar classes NamedTuple (por exemplo, Point = NamedTuple("Point", x=int, y=int)) foi descontinuada desde o Python 3.13. Em vez disso, use as sintaxes baseada em classe ou funcional.

    • Ao usar a sintaxe funcional de TypedDicts, não passar um valor para o parâmetro fields (TD = TypedDict("TD")) ou passar None (TD = TypedDict("TD", None)) foi está descontinuado desde o Python 3.13. Use class TD(TypedDict): pass ou TD = TypedDict("TD", {}) para criar uma classe TypedDict com nenhum campo.

    • A função decoradora typing.no_type_check_decorator() foi descontinuada desde o Python 3.13. Após oito anos no módulo typing, ela ainda não foi suportada por nenhum verificador de tipo importante.

  • wave:

  • zipimport:

Remoção pendente no Python 3.16

  • O sistema de importação:

    • A definição de __loader__ em um módulo enquanto falha na definição de __spec__.loader está descontinuado. No Python 3.16, __loader__ deixará de ser definido ou levado em consideração pelo sistema de importação ou pela biblioteca padrão.

  • array:

    • O código de formato 'u' (wchar_t) foi descontinuado na documentação desde o Python 3.3 e do ambiente de execução desde o Python 3.13. Em vez disso, use o código de formato 'w' (Py_UCS4) para caracteres Unicode.

  • asyncio:

  • builtins:

    • A inversão bit a bit em tipos booleanos, ~True ou ~False foi descontinuada desde o Python 3.12, pois produz resultados surpreendentes e não intuitivos (-2 e -1). Em vez disso, use not x para a negação lógica de um booleano. No caso raro de você precisar da inversão bit a bit do inteiro subjacente, converta para int explicitamente (~int(x)).

  • functools:

    • A chamada da implementação Python de functools.reduce() com function ou sequence como argumentos nomeados foi descontinuada desde o Python 3.14.

  • logging:

    O suporte para manipuladores de registro personalizados com o argumento strm foi descontinuado e está programado para ser removido no Python 3.16. Em vez disso, defina manipuladores com o argumento stream. (Contribuição de Mariusz Felisiak em gh-115032.)

  • mimetypes:

    • Extensões válidas começam com um ‘.’ ou estão vazias para mimetypes.MimeTypes.add_type(). Extensões sem ponto estão descontinuadas e levantarão uma exceção ValueError no Python 3.16. (Contribuição de Hugo van Kemenade em gh-75223.)

  • shutil:

    • A exceção ExecError foi descontinuada desde o Python 3.14. Ela não foi usada por nenhuma função em shutil desde o Python 3.4, e agora é um alias de RuntimeError.

  • symtable:

  • sys:

  • sysconfig:

    • A função sysconfig.expand_makefile_vars() está descontinuada desde o Python 3.14. Em vez disso, use o argumento vars de sysconfig.get_paths().

  • tarfile:

    • O atributo não documentado e não utilizado TarFile.tarfile foi descontinuado desde o Python 3.13.

Remoção pendente no Python 3.17

  • typing:

    • Antes do Python 3.14, as uniões antigas eram implementadas usando a classe privada typing._UnionGenericAlias. Essa classe não é mais necessária para a implementação, mas foi mantida para compatibilidade com versões anteriores, com remoção prevista para o Python 3.17. Os usuários devem usar auxiliares de introspecção documentados, como typing.get_origin() e typing.get_args(), em vez de depender de detalhes de implementação privada.

Remoção pendente no Python 3.19

  • ctypes:

    • Troca implícita para o layout de estrutura compatível com MSVC definindo _pack_, mas não _layout_ em plataformas não Windows.

Remoção pendente em versões futuras

As APIs a seguir serão removidas no futuro, embora atualmente não haja uma data agendada para sua remoção.

  • argparse:

    • O aninhamento de grupos de argumentos e o aninhamento de grupos mutuamente exclusivos estão descontinuado.

    • A passagem do argumento nomeado não documentado prefix_chars para add_argument_group() agora está descontinuado.

    • O conversor de tipo argparse.FileType está descontinuado.

  • builtins:

    • bool(NotImplemented).

    • Geradores: a assinatura throw(type, exc, tb) e athrow(type, exc, tb) está descontinuada: use throw(exc) e athrow(exc), a assinatura do argumento único.

    • Atualmente Python aceita literais numéricos imediatamente seguidos por palavras reservadas como, por exemplo, 0in x, 1or x, 0if 1else 2. Ele permite expressões confusas e ambíguas como [0x1for x in y] (que pode ser interpretada como [0x1 for x in y] ou [0x1f or x in y]). Um aviso de sintaxe é levantado se o literal numérico for imediatamente seguido por uma das palavras reservadas and, else, for, if, in , is e or. Em uma versão futura, será alterado para um erro de sintaxe. (gh-87999)

    • Suporte para métodos __index__() e __int__() retornando tipo não-int: esses métodos serão necessários para retornar uma instância de uma subclasse estrita de int.

    • Suporte para o método __float__() retornando uma subclasse estrita de float: esses métodos serão necessários para retornar uma instância de float.

    • Suporte para o método __complex__() retornando uma subclasse estrita de complex: esses métodos serão necessários para retornar uma instância de complex.

    • Delegação do método int() para o __trunc__().

    • Passar um número complexo como argumento real ou imag no construtor complex() agora está descontinuado; deve ser passado apenas como um único argumento posicional. (Contribuição de Serhiy Storchaka em gh-109218.)

  • calendar: as constantes calendar.January e calendar.February foram descontinuadas e substituídas por calendar.JANUARY e calendar.FEBRUARY. (Contribuição de Prince Roshan em gh-103636.)

  • codecs: use open() em vez de codecs.open(). (gh-133038)

  • codeobject.co_lnotab: use o método codeobject.co_lines().

  • datetime:

    • utcnow(): use datetime.datetime.now(tz=datetime.UTC).

    • utcfromtimestamp(): use datetime.datetime.fromtimestamp(timestamp, tz=datetime.UTC).

  • gettext: o valor de plural deve ser um número inteiro.

  • importlib:

    • O parâmetro debug_override de cache_from_source() foi descontinuado: use o parâmetro optimization.

  • importlib.metadata:

    • Interface de tupla EntryPoints.

    • None implícito nos valores de retorno.

  • logging: o método warn() foi descontinuado desde o Python 3.3, use warning().

  • mailbox: o uso da entrada StringIO e do modo de texto foi descontinuado; em vez disso, use BytesIO e o modo binário.

  • os: chame os.register_at_fork() em processo multithread.

  • pydoc.ErrorDuringImport: um valor de tupla para o parâmetro exc_info foi descontinuado, use uma instância de exceção.

  • re: regras mais rigorosas agora são aplicadas para referências numéricas de grupos e nomes de grupos em expressões regulares. Apenas a sequência de dígitos ASCII agora é aceita como referência numérica. O nome do grupo em padrões de bytes e strings de substituição agora pode conter apenas letras e dígitos ASCII e sublinhado. (Contribuição de Serhiy Storchaka em gh-91760.)

  • Módulos sre_compile, sre_constants e sre_parse.

  • shutil: o parâmetro onerror de rmtree() foi descontinuado no Python 3.12; use o parâmetro onexc.

  • Protocolos e opções de ssl

    • ssl.SSLContext sem argumento de protocolo foi descontinuado.

    • ssl.SSLContext: set_npn_protocols() e selected_npn_protocol() foram descontinuados, use ALPN.

    • Opções de ssl.OP_NO_SSL*

    • Opções de ssl.OP_NO_TLS*

    • ssl.PROTOCOL_SSLv3

    • ssl.PROTOCOL_TLS

    • ssl.PROTOCOL_TLSv1

    • ssl.PROTOCOL_TLSv1_1

    • ssl.PROTOCOL_TLSv1_2

    • ssl.TLSVersion.SSLv3

    • ssl.TLSVersion.TLSv1

    • ssl.TLSVersion.TLSv1_1

  • Métodos de threading:

  • typing.Text (gh-92332).

  • A classe interna typing._UnionGenericAlias não é mais usada para implementar typing.Union. Para preservar a compatibilidade com usuários que utilizam esta classe privada, uma correção de compatibilidade será fornecida pelo menos até a versão 3.17 do Python. (Contribuição de Jelle Zijlstra em gh-105499.)

  • unittest.IsolatedAsyncioTestCase: foi descontinuado retornar um valor que não seja None de um caso de teste.

  • Funções descontinuadas de urllib.parse: use urlparse()

    • splitattr()

    • splithost()

    • splitnport()

    • splitpasswd()

    • splitport()

    • splitquery()

    • splittag()

    • splittype()

    • splituser()

    • splitvalue()

    • to_bytes()

  • wsgiref: SimpleHandler.stdout.write() não deve fazer gravações parciais.

  • xml.etree.ElementTree: testar o valor verdade de um Element está descontinuado. Em um lançamento futuro isso sempre retornará True. Em vez disso, prefira os testes explícitos len(elem) ou elem is not None.

  • sys._clear_type_cache() está descontinuada: use sys._clear_internal_caches().

Alterações de bytecode do CPython

  • Substituído o opcode BINARY_SUBSCR por BINARY_OP com oparg NB_SUBSCR. (Contribuição de Irit Katriel em gh-100239.)

Alterações na construção

  • O GNU Autoconf 2.72 agora é necessário para gerar o configure. (Contribuição de Erlend Aasland em gh-115765.)

  • A vinculação baseada em #pragma com python3*.lib agora pode ser desativada com Py_NO_LINK_LIB. (Contribuição de Jean-Christophe Fillion-Robin em gh-82909.)

PEP 761: Descontinuação de assinaturas PGP

As assinaturas PGP não estarão disponíveis para o CPython 3.14 e versões posteriores. Usuários que verificarem artefatos devem usar materiais de verificação da Sigstore para verificar artefatos do CPython. Essa alteração no processo de lançamento está especificada na PEP 761.

Alterações na API C

Novas funcionalidades

Mudanças na API C limitada

Descontinuados

Remoção pendente no Python 3.15

Remoção pendente no Python 3.16

  • A cópia empacotada do libmpdec.

Remoção pendente no Python 3.18

Remoção pendente em versões futuras

As APIs a seguir foram descontinuadas e serão removidas, embora atualmente não haja uma data agendada para sua remoção.

Removidos

  • A criação de tipos imutáveis com bases mutáveis foi descontinuada desde a versão 3.12 e agora levanta TypeError.

  • Remove o membro PyDictObject.ma_version_tag, que estava descontinuado desde o Python 3.12. Em vez disso, use a API PyDict_AddWatcher(). (Contribuição de Sam Gross em gh-124296.)

  • Remova a função privada _Py_InitializeMain(). Era uma API provisória adicionada ao Python 3.8 pela PEP 587. (Contribuição de Victor Stinner em gh-129033.)

  • As APIs não documentadas Py_C_RECURSION_LIMIT e PyThreadState.c_recursion_remaining, adicionadas na versão 3.13, foram removidas sem um período de descontinuação. Use Py_EnterRecursiveCall() para se proteger contra recursão descontrolada em código C. (Removidas em gh-133079, veja também gh-130396.)

Portando para o Python 3.14

Esta seção lista as alterações descritas anteriormente e outras correções que podem exigir alterações no seu código.

Alterações na API Python

  • functools.partial agora é um descritor de método. Envolva-o em staticmethod() se quiser preservar o comportamento antigo. (Contribuição de Serhiy Storchaka e Dominykas Grigonis em gh-121027.)

  • O coletor de lixo agora é incremental, o que significa que o comportamento de gc.collect() muda ligeiramente:

    • gc.collect(1): Executa um incremento da coleta de lixo, em vez de coletar a geração 1.

    • Outras chamadas para gc.collect() não foram alteradas.

  • A função locale.nl_langinfo() agora define temporariamente a localidade LC_CTYPE em alguns casos. Esta alteração temporária afeta outras threads. (Contribuição de Serhiy Storchaka em gh-69998.)

  • types.UnionType agora é um apelido para typing.Union, causando alterações em alguns comportamentos. Veja acima para mais detalhes. (Contribuição de Jelle Zijlstra em gh-105499.)

  • O comportamento das anotações em tempo de execução mudou de várias maneiras; veja acima para mais detalhes. Embora a maioria dos códigos que interagem com anotações deva continuar funcionando, alguns detalhes não documentados podem se comportar de forma diferente.

Changes in the C API

  • Py_Finalize() now deletes all interned strings. This is backwards incompatible to any C extension that holds onto an interned string after a call to Py_Finalize() and is then reused after a call to Py_Initialize(). Any issues arising from this behavior will normally result in crashes during the execution of the subsequent call to Py_Initialize() from accessing uninitialized memory. To fix, use an address sanitizer to identify any use-after-free coming from an interned string and deallocate it during module shutdown. (Contributed by Eddie Elizondo in gh-113601.)

  • A API C objetos de exceção Unicode agora levanta TypeError se o argumento de exceção não for um objeto UnicodeError. (Contribuição de Bénédikt Tran em gh-127691.)