- O Python Steering Council sinalizou disposição para aceitar a PEP 703, e a remoção do GIL no CPython entrou em um longo processo gradual, indo de builds experimentais até uma possível mudança do modo padrão
- Remover o GIL pode destravar o desempenho com múltiplas threads, mas também pode trazer custos para o desempenho em thread única, que domina a maior parte do ecossistema atual, além da compatibilidade com extensões em C
- A equipe do Faster CPython avalia que o interpretador adaptativo especializado baseado na PEP 659 depende do GIL, então em um ambiente sem GIL será preciso recalcular a estratégia de otimização e o custo de manutenção
- A Meta afirmou que, se a PEP 703 for aceita, investirá 3 engineer-years até o fim de 2025, e a Anaconda prometeu apoiar o trabalho de empacotamento envolvendo pip, cibuildwheel e conda-forge
- A transição busca evitar uma ruptura como a do Python 2→3 e, se concluírem que a confusão do no-GIL supera os benefícios, o plano ainda poderá ser revertido antes de virar o modo padrão
O debate sobre remover o GIL do Python volta a ganhar força
- O Global Interpreter Lock (GIL) do Python serializa o acesso à máquina virtual do interpretador para que apenas uma thread execute código Python por vez
- O GIL, que há muito tempo impede ganhos de desempenho com várias threads, é frequentemente citado como uma fraqueza histórica do Python
- Em outubro de 2021, Sam Gross publicou uma versão de prova de conceito do Python sem GIL, e após o interesse inicial houve pouco avanço por mais de um ano
- Depois disso, o Python Steering Council anunciou sua disposição para aceitar a funcionalidade no-GIL
- Ainda levará tempo até isso entrar em uma versão lançada de fato
- Continua existindo a possibilidade de o trabalho ser revertido em algum momento no futuro
- O apoio de várias empresas aumenta as chances de sucesso
A tensão entre o Faster CPython e o desempenho em thread única
- Na Python Language Summit de 2022, Gross apresentou o fork no-GIL tentando obter um consentimento implícito para levar o trabalho adiante, mas não houve consenso porque os impactos detalhados ainda não eram suficientemente conhecidos
- Na mesma época, o projeto Faster CPython estava focado em melhorar o desempenho do interpretador em thread única
- Mark Shannon escreveu a PEP 659, “Specialized Adaptive Interpreter”, e parte dessas mudanças entrou no Python 3.10 e 3.11
- Na PyCon, Brandt Bucher, da equipe Faster CPython, apresentou as instruções adaptativas, e Shannon falou sobre melhorias no layout de memória e outras técnicas de otimização
- Como quase todos os programas Python existentes são escritos para rodar em thread única por causa do GIL, melhorar o desempenho em thread única afeta diretamente o desempenho percebido de todo o ecossistema Python
A proposta da PEP 703 e as preocupações iniciais
- Em janeiro de 2023, Łukasz Langa publicou a primeira versão da PEP 703, escrita por Gross: “Making the Global Interpreter Lock Optional in CPython”
- Junto com a expectativa em torno do no-GIL, extensões Python escritas em C surgiram como uma preocupação central
- O GIL vinha servindo para evitar vários problemas de concorrência em código de extensões C
- Removê-lo pode introduzir novos bugs nesse código
- Havia consenso de que era preciso evitar uma transição em flag day como a da passagem do Python 2 para o 3
- A transição para remover o GIL precisa funcionar de forma suave até mesmo com código que ainda não esteja pronto
- Shannon perguntou qual seria uma perda de desempenho aceitável em código de thread única; sua estimativa direta ficou na faixa de 15~20%, podendo ser maior dependendo do impacto sobre a PEP 659
- Eric Snow, autor da PEP 684 “Per-Interpreter GIL” e da PEP 683 “Immortal Objects”, publicou uma análise longa e avaliou que a abordagem no-GIL e a de subinterpretadores não necessariamente entram em conflito
Custos e ganhos para extensões em C
- Gross respondeu que o impacto sobre extensões em C não é totalmente negativo
- A PEP inclui citações de mantenedores de extensões amplamente usadas da API C sobre a complexidade enfrentada ao contornar o GIL
- Zachary DeVito, desenvolvedor principal do PyTorch, afirmou que nos últimos meses gastou, em três ocasiões, um tempo de um dígito a mais tentando entender como contornar as limitações do GIL do que resolvendo o problema real em si
- O no-GIL pode criar novos problemas de concorrência para mantenedores de módulos de extensão, mas ao mesmo tempo também pode reduzir a complexidade necessária para evitar o GIL
PEP atualizada e debate sobre desempenho
- No começo de maio de 2023, Gross publicou uma implementação da PEP 703 baseada em uma versão de desenvolvimento do Python 3.12, junto com uma PEP atualizada
- Em 12 de maio, ele pediu uma decisão do Steering Council sobre a PEP, mas mais discussões continuaram antes da decisão
- Em 2 de junho, Shannon avaliou o impacto de desempenho da PEP e apresentou uma faixa de 11~30%, o que gerou controvérsia
- Shannon considera que o interpretador adaptativo com especialização depende do GIL, então, se o no-GIL for aceito, será necessário redesenhar a estratégia de otimização
- O esforço gasto em redesenho e implementação deixaria de ser aplicado ao trabalho efetivo de otimização
- Langa publicou números de benchmark mostrando um impacto muito menor do que a estimativa de Shannon, e resultados adicionais ficaram próximos do que Gross havia reportado na PEP
Lições aprendidas na transição do Python 2→3
- Guido van Rossum avalia que a transição teria sido ajudada se código Python 2 e 3 pudesse coexistir no mesmo interpretador
- Se o no-GIL avançar, ele enfatiza que módulos de extensão que exigem GIL também devem poder ser importados em um interpretador no-GIL sem trabalho adicional
- O código da aplicação não deve precisar ser alterado
- Os módulos de extensão também não devem precisar ser alterados
- Gregory P. Smith, do Steering Council, afirmou que o alcance do impacto da PEP 703 é tão grande que o conselho ainda não estava pronto para tomar uma decisão imediata
- Smith reconheceu que existe demanda, mas defendeu que é preciso considerar todo o ecossistema e encontrar uma forma de transição que não quebre o mundo
- Gross respondeu que adiar a decisão sem critérios claros de aceitação e sem cronograma acaba funcionando, na prática, como um “não”
As três opções vistas pela equipe Faster CPython
- Em “A fast, free threading Python”, Shannon resumiu três caminhos possíveis para seguir adiante
- Buscar um interpretador rápido em thread única conforme o plano atual
- Buscar um interpretador free-threading sem GIL, com impacto desconhecido, mas não nulo, no desempenho em thread única
- Buscar os dois ao mesmo tempo
- Shannon avalia que será preciso escolher o que limitar entre desempenho, paralelismo e mutabilidade
- Em vez de “Performance, parallelism, mutability: pick two”, ele descreve a situação como algo mais próximo de “pick one to restrict”
- Ele alertou que tornar o Python rápido em um ambiente free-threading exigirá pesquisa original, com custo e risco maiores
- Sua preferência era a terceira opção, mas ele considera inadequado escolher apenas o no-GIL e esperar que “alguém” resolva os problemas de desempenho depois
- Van Rossum também considera ideal obter free threading junto com alto desempenho por thread, mas ressaltou a necessidade de recursos adicionais
Apoio das empresas e opinião dos desenvolvedores centrais
- Van Rossum afirmou que a Microsoft continuará apoiando a equipe Faster CPython, e que o papel dessa equipe não se limita ao trabalho de desempenho em thread única
- A meta é ajustar o trabalho de especialização e otimização para um mundo no-GIL, de modo que, no fim, o no-GIL se torne o único modo de build sem perda de desempenho em thread única
- Carl Meyer, da Meta, afirmou que, se a PEP 703 for aceita, a empresa investirá 3 engineer-years até o fim de 2025
- Engenheiros com experiência interna em CPython trabalharão em conjunto com a equipe de core devs
- A implementação da PEP 703 será integrada ao CPython de forma suave
- A compatibilidade e o desempenho do CPython sem GIL continuarão sendo melhorados
- Stan Seibert, da Anaconda, declarou que apoiará os problemas de empacotamento decorrentes da adoção da PEP 703
- Incluindo trabalho relacionado a pip, cibuildwheel e conda-forge
- Incluindo o trabalho necessário para entregar pacotes compatíveis com no-GIL à comunidade Python
- Em uma pesquisa com core developers, 87% de 46 responderam que o Python free-threaded deve ser perseguido ativamente, e 63% de 38 disseram estar dispostos a contribuir para o suporte e a manutenção de um Python sem GIL baseado na PEP 703
A decisão do Steering Council e a transição gradual
- Em 28 de julho, Thomas Wouters anunciou que o Steering Council decidiu aceitar a PEP 703, embora os detalhes dessa aceitação ainda estivessem sendo trabalhados
- A ideia é introduzir primeiro um interpretador no-GIL, identificar o que ainda falta e preencher esse trabalho antes de o no-GIL virar o padrão e, no fim, a única versão
- O período de transição é estimado em cerca de 5 anos
- O Council não quer repetir uma situação como a do Python 3 e considera que quaisquer mudanças necessárias em código de terceiros para se adequar ao build no-GIL também devem continuar funcionando no build com GIL
- No curto prazo, foi proposto um build experimental sem GIL, possivelmente já no Python 3.13
- O Python 3.13 está previsto para outubro de 2024
- Será um build para experimentação por core developers e outras pessoas
- No médio prazo, o no-GIL se tornará uma opção suportada, mas não o padrão
- O momento disso dependerá fortemente da velocidade com que a comunidade adotar e der suporte ao build no-GIL
- No longo prazo, o no-GIL se tornará o build padrão e o GIL será removido por completo
- Isso deve acontecer de forma a não quebrar a compatibilidade retroativa desnecessariamente
O trabalho ainda não acabou
- Wouters considera que remover o GIL é um trabalho muito maior do que simplesmente aceitar uma PEP
- Os core developers precisarão acumular experiência prática com Python sem GIL e, com base nisso, conduzir o restante da comunidade
- Ao organizar a segurança de thread do código existente, pode ser necessário criar novas APIs em C e APIs Python
- Ao longo de todo o processo, o andamento e o cronograma devem ser reavaliados periodicamente
- Isso não pode virar outra batalha de compatibilidade retroativa que dure 10 anos
- Se a PEP 703 parecer problemática, deve ser possível interromper o caminho e buscar outra solução
- Ainda há muito trabalho de pesquisa, codificação, testes, experimentação e documentação até um Python exclusivamente no-GIL; como exemplo, menciona-se o Python 3.17, que poderia chegar em outubro de 2028
1 comentários
Opiniões do Hacker News
O texto é bem escrito e resume bem todo o processo, mas tende a dar mais peso ao lado contra a remoção do GIL e à possibilidade de fracasso
Também é preciso enfatizar adequadamente o outro lado. A qualidade do trabalho de Sam Gross é muito alta, e ele também incluiu melhorias de desempenho não diretamente relacionadas ao no-GIL para reduzir a perda de performance. O projeto também avançou muito bem no modelo open source, e ele demonstrou paciência apesar de a resposta ter sido tão lenta que, sem a pressão da comunidade, o comitê diretor provavelmente teria continuado deixando o assunto parado. Subinterpretadores ainda quase nunca demonstraram utilidade em Python, especialmente com métricas sérias, e esta parece ser uma das primeiras tentativas bem definidas e medidas. A reação da comunidade também mostrou grande interesse neste projeto, e o comitê diretor concluiu que “tem a intenção de aceitar a PEP 703 e está ajustando os detalhes das condições de aceitação”. Não sou um defensor fervoroso do no-GIL, acho ok se ele acabar não sendo removido e acredito que subinterpretadores deveriam ser tentados primeiro, mas é preciso analisar a questão de forma justa
Os resultados também são bastante impressionantes: https://lwn.net/SubscriberLink/941090/8bcb029dbf548f26/. Parece ter saído tão bem quanto se poderia esperar. O trabalho em subinterpretadores deve seguir em paralelo com o trabalho de free-threading, e os dois têm casos de uso diferentes
Pelo que sei, o PDM ainda oferece suporte a isso. Não gosto de usar virtualenv para build e distribuição, e gostaria que Python também pudesse se comportar como JavaScript. Já foi provado que é possível. A thread de discussão está em https://discuss.python.org/t/pep-582-python-local-packages-d.... Também é frustrante ver “exatamente uma forma correta” sendo usado como motivo de rejeição, porque nunca senti que essa frase fosse verdadeira em Python
É um excelente artigo da LWN e valeu muito a leitura. Quando o NoGIL de Sam Gross apareceu pela primeira vez, fiquei animado, mas, depois de ler o artigo e refletir sobre minha experiência pessoal, comecei a mudar de ideia
Já construí sistemas backend em várias linguagens, e em geral eles eram de apenas dois tipos. Um abria endpoints de rede, recebia requisições, fazia cálculos e outras requisições de rede e então respondia; o outro lia mensagens de uma fila, banco de dados, polling de outras APIs etc., fazia cálculos e chamadas de rede e então enviava para outra fila. No primeiro caso, latência é importante; no segundo, throughput é importante. No primeiro tipo, o NoGIL é útil porque você quer criar threads conforme as requisições, evitar que um endpoint pesado em cálculo bloqueie outras requisições e compartilhar pools de conexões com o banco de dados. No segundo tipo, mesmo em linguagens sem GIL, quase não me lembro de usar paralelismo ou concorrência dentro do mesmo processo com recursos compartilhados, porque fica difícil demais de entender. A otimização normalmente era processamento em lotes inteligente, e o paralelismo consistia em subir vários processos independentes em várias máquinas. Se a qualidade dos sistemas do segundo tipo for comprometida por causa do NoGIL, acho que seria bastante decepcionante; na prática, hoje a maior parte da minha energia mental está sendo usada para melhorar esse segundo tipo
Hoje implemento o JournalParser com QThread; esse parser lê continuamente, nos arquivos de diário do jogador gerados por Elite: Dangerous e Odyssey, os eventos do jogo, e emite QSignals personalizados por evento, que são processados pelos slots que escutam esses sinais. Em outras partes da aplicação, não ter o GIL também poderia ser bem útil. https://captainslog.scarygliders.net/captains-log-2/
Com isso, o código de todo mundo pode melhorar
Claro, alguém poderia dizer que programas centrados em CPU nem deveriam ser escritos em Python para começo de conversa, mas isso já é outra história
Se o recurso compartilhado for somente leitura, não entendo muito bem por que isso seria confuso
É duvidoso se a frase no thread linkado — “é muito improvável que a remoção do GIL quebre bases de código feitas apenas em Python” — está de fato correta
Alguns códigos Python multithread podem esperar, graças ao GIL, que certas operações sejam implicitamente thread-safe. Por exemplo, se duas threads adicionarem itens à mesma lista, a lista não é corrompida porque, por causa do GIL, as duas threads não executam essa operação em paralelo. Ao remover o GIL, esse tipo de código pode de repente ser punido, como ao modificar simultaneamente um
std::vectorem C++. Não tenho certeza, mas essa frase parece um pouco suspeita. https://discuss.python.org/t/pep-703-making-the-global-inter...mapsimultaneamente causa um panicA seção segurança de threads de contêineres da PEP 703 trata desse problema. Ela propõe colocar um bloqueio leve por objeto em cada list, dictionary e set; todas as operações que modificam o objeto devem adquirir esse bloqueio, e a maioria das operações de leitura também deve adquiri-lo. Mais detalhes estão em https://peps.python.org/pep-0703/#container-thread-safety
Mas aí fica a questão do que fazer quando for necessário um
[]não sincronizadoÉ difícil imaginar uma prova de fogo mais complicada que esta no open source
A decisão em si é razoável. Avançar em modo de teste, tratar múltiplos interpretadores como um experimento intermediário, mas definir como objetivo um Python capaz de execução concorrente. Ainda assim, a restrição de rodar código existente e código novo na mesma máquina virtual é enorme. É surpreendente que o resumo da LWN quase não tenha tratado dos testes; os testes ainda estão longe de resolvidos e podem levar a releases com bugs desconhecidos, porém graves. Microsoft, Facebook/Meta e Conda estão contribuindo com recursos, e a esmagadora maioria dos principais contribuidores quer avançar, mas não está claro o que acontecerá se o trabalho ficar mais difícil e exigir mais gente. Ao mesmo tempo, enormes projetos acadêmicos e industriais — de websites a big data e IA — dependem de Python, e o custo repassado aos desenvolvedores Python pode até ser medido como fração do PIB. Como nem parece que os problemas ainda estejam conhecidos, seria melhor concentrar-se na abordagem Faster CPython, fazendo melhorias previsíveis ao longo dos próximos 3 anos ou mais, enquanto os defensores do Python com execução concorrente deveriam ir além de protótipos simples e analisar que problemas podem surgir, como detectá-los e o que pode ser feito. Seria mais justo que pessoas com experiência em provar garantias de concorrência revisassem o assunto, e que as perguntas fossem levadas ao comitê diretor depois que ao menos os desconhecidos fossem identificados. No open source não houve muitas decisões em escala de gestão de programa; houve muitas decisões relativamente simples que direcionavam o mercado, como Apache, Eclipse e Linux, mas desta vez há incógnitas técnicas reais. Ao mesmo tempo, sinto que a ABI entre linguagens também precisa ser tratada. O grande problema é alinhar-se ao modelo de execução esperado por C; a interface de funções externas e memória do Java está em incubação há anos, e o Swift também tem melhorado o wrapping de C e C++, mas FFI é notoriamente difícil e talvez desnecessariamente difícil
Na minha opinião pessoal, remover o GIL é um erro. Não há muitos aplicativos que se beneficiariam fortemente, e a maioria sofrerá penalidade de desempenho
Esse trabalho vai consumir anos de atenção e esforço, que talvez pudessem ser usados de forma mais inteligente. Python parece ter uma certa ansiedade ou complexo de inferioridade em relação ao GIL. Acho que seria melhor abraçar totalmente um modelo single-thread, como o JavaScript. Alguns aplicativos continuariam difíceis ou impossíveis, mas não acho que Python seja uma boa escolha para apps que exigem alto desempenho ou alta escalabilidade. Ser um pouco especializado e não oferecer suporte a todos os casos de uso não é necessariamente ruim
As pessoas precisam de desempenho para o que já estão fazendo hoje com Python. Não dá para voltar a uma época em que isso não era verdade. Agora esse é um dos casos de uso mais comuns de Python, e as pessoas estão apostando suas carreiras nisso
As pessoas já estão tentando fazer trabalho paralelo com Python. Forçá-las a usar outra linguagem não ajuda muito
Muitas tarefas intensivas em dados podem ser executadas facilmente como processos paralelos em Python, então não sei se a remoção do GIL traria um ganho tão grande
O desempenho em thread única deve ter mais prioridade, porque é muito mais difícil melhorá-lo simplesmente colocando mais dinheiro
O desempenho multithread pode compensar a sobrecarga da paralelização baseada em processos adicionando mais um core. Acho que a própria dicotomia GIL vs. no-GIL está errada. O maior problema em
multiprocessingé não poder compartilhar memória. Portanto, bastaria adicionar processos virtuais com um mecanismo explícito de compartilhamento de memória. Assim, os objetos permaneceriam em uma única thread, permitindo manter otimizações de thread única, como contagem de referências sem barreirasÉ possível ter bom desempenho em thread única mesmo sem GIL. Rust tem o conceito de abstrações sem custo e também lida bem com threads. Java também vai bem em tarefas de thread única. Há muitas outras linguagens; isso não é ficção científica. Locks podem desaparecer por otimização, também é possível optar por código sem locks, e concorrência granular ou estruturada também é viável. O que é thread-safe é, basicamente, um contrato de API. Locking otimista também existe. Não há uma boa razão para Python não conseguir fazer algo parecido, mas primeiro é preciso remover o GIL. A perda de desempenho do Python sem GIL é, em grande parte, algo próximo de uma dívida técnica não resolvida e pode ser corrigida com o tempo. Colocar muitos locks é um paliativo e deixa tudo mais lento, mas a solução adequada provavelmente será repensar o funcionamento interno ou ter contratos de API que documentem se algo é thread-safe. Um runtime e um compilador Python mais rápidos também permitirão reimplementar em Python muita coisa que hoje depende de bibliotecas nativas. A interação com código nativo é justamente onde há muitos pontos que exigem locks, e, se esse modelo não mudar, continuará sendo um problema. O ponto central da remoção do GIL é encontrar e corrigir sistematicamente essas coisas, e isso deve melhorar com o tempo
multiprocessing, então multithreading no-GIL tem pouca utilidadeO único problema de Python/
multiprocessingé que às vezes é necessário estado mutável compartilhado, não uma fila. A forma atual de colocar objetos Python em memória compartilhada é complexa, limitada e ineficiente. Esse é o alvo a ser corrigido, e Python precisa de suporte melhor para colocar instâncias nativas em memória compartilhadaÀ pergunta “quanta perda de desempenho em código de thread única seria aceitável”, Shannon estimou algo em torno de 15% a 20%, mas a pergunta, em geral, ficou sem resposta
Então algumas pessoas do projeto que está tornando o “CPython mais rápido” acham aceitável tornar a maior parte do código Python existente 15% a 20% mais lenta da noite para o dia? Para mim, o limite seria algo em torno de 5%. E mesmo assim só se a remoção do GIL ajudasse outras otimizações futuras. Mas dizem que, pelo contrário, essa mudança complica e atrasa outras otimizações. Por outro lado, em 2020 Shannon propôs pessoalmente uma campanha de financiamento para tornar o CPython 5 vezes mais rápido, e agora uma equipe inteira, com apoio corporativo muito maior, está trabalhando para acelerar o CPython, mas a meta parece muito menor
Quando desempenho realmente importa, conseguir um ganho de velocidade de cerca de 20 vezes sem precisar reescrever em outra linguagem faz muita diferença
Se outras otimizações não forem interrompidas, mas apenas levarem um pouco mais de tempo, talvez isso seja aceitável
Comparando código real com operações numéricas e de strings, sem acesso a rede ou disco, o beta do 3.12 leva apenas cerca de 20% a 25% menos tempo que o 3.8. Isso está no nível do 2.7. Parece que figuras centrais antigas estão desesperadas por recursos em bullet points para mostrar a patrocinadores corporativos no próximo release. Por isso usam o trabalho de Sam Gross, mas, com o tempo, é provável que o crédito vá sendo lentamente apropriado por eles
Um excelente resumo, como é típico da LWN
Gosto da comunidade Python. Ela é um exemplo de liderança em software open source e mostra o que transparência e boa governança podem alcançar. O tempo de engenharia investido por Meta, Microsoft e outras é bem-vindo, mas ainda é pequeno demais em comparação com o valor que toda a indústria de tecnologia e áreas mais amplas, incluindo ciência de dados, obtêm de Python e do software open source
Há 8 anos, no JPMorgan, convenci a equipe de liderança técnica a patrocinar a PyCon UK, montar um estande de recrutamento e apoiar a participação de desenvolvedores juniores do JPMorgan de todo o Reino Unido. Saí do JPM há 5 anos, mas eles ainda são o patrocinador principal da PyCon UK. Era um custo praticamente desprezível em comparação com os enormes benefícios obtidos do ecossistema Python e open source
As listas de e-mail são censuradas, e o círculo interno não pode ser criticado. Os verdadeiros contribuidores são explorados por pessoas que pertencem às empresas certas, fazem pouco e ocupam cargos administrativos de autoridade. Os textos da LWN são muito favoráveis e sempre mencionam bem os nomes dos decisores, então não se deve cair nessa. Para mim, parece uma cobertura seletiva
A forma como Sam Gross levou isso adiante é bastante impressionante. Depois de receber uma resposta positiva, mas sem compromisso, do comitê diretor, ele poderia ter simplesmente ficado sentado esperando progresso; em vez disso, o fato de ter se oposto e pressionado merece grande reconhecimento
Muito interessante. Quando Sam Gross disse que “não precisamos de um yes/no agora, mas precisamos saber como seria a aceitação, e esta issue ficou abandonada por tempo demais”, foi um movimento bastante ousado: https://github.com/python/steering-council/issues/188#issuec...
Aquela interação poderia ter seguido vários caminhos, mas parece que foi exatamente o estímulo de que o comitê diretor precisava. Ainda há um caminho longo e sinuoso até um Python sem GIL, e provavelmente será necessário um esforço na casa de dezenas de engenheiro-anos, mas ao menos parece que agora existe um caminho adequado. A parte mais difícil é garantir a correção da base de código existente. Dizer que não se quer repetir a transição do Python 2 para o 3 é uma coisa; na prática, evitar a atualização por medo de bugs, mesmo que se afirme que não haverá mudanças incompatíveis, é outra completamente diferente. Mesmo deixar GIL/no-GIL apenas como uma opção em tempo de compilação certamente aumenta o custo de manutenção. Ainda assim, no longo prazo, acho que esse esforço valerá a pena. O GIL é uma espécie de para-raios para críticas ao Python, como se vê em qualquer thread do HN sobre Python e paralelismo. Talvez porque seja algo para o qual as pessoas possam apontar diretamente e dizer “é por isso que o Python não consegue ficar mais rápido”, sem entender décadas de contexto. Nesse sentido, é quase o chefão final da cerca de Chesterton
Mesmo sob as novas diretrizes, ainda há a possibilidade de que o esforço de vários anos para remover o GIL acabe sendo rejeitado