O que a build free-threaded da PEP 703 muda para o código que você escreve?

A build free-threaded, entregue como interpretador opcional desde o CPython 3.13, remove o GIL para que várias threads possam rodar bytecode Python em paralelo. Seu código passa a ser genuinamente concorrente, o que significa que as corridas que o GIL escondia agora são reais. Você precisa de locks explícitos em torno de estado mutável compartilhado, e precisa checar se cada extensão C da qual você depende tem suporte.

O free threading chegou como build experimental na 3.13 e vem amadurecendo desde então, e o ponto principal é que é um interpretador separado no qual você opta, não algo que mudou silenciosamente para todo mundo. Sem o lock, duas threads podem rodar bytecode em dois cores ao mesmo tempo, então um pool de workers CPU bound finalmente escala sem pagar custo de startup de processo e de pickling. A troca é correção. Na build antiga, muito código desleixado se safava com updates de dict sem sincronização porque uma fronteira de bytecode raramente caía no lugar errado. Agora essas são corridas de dados de verdade e você precisa de um Lock ou de uma queue. Testei num job de scoring que estava distribuindo trabalho para quatro processos, e as threads deram throughput parecido com uma pegada de memória bem menor, já que o modelo ficava carregado uma vez em vez de quatro. O bloqueio para produção foram as extensões. Qualquer coisa com camada C precisa ser recompilada contra a ABI free threaded, então antes de subir isso eu auditaria a árvore de dependências e veria o que os mantenedores publicaram.