Referes a um patch amador que nem sequer faz parte do repositório do CPython? Acho que serve de exemplo fantástico...
Não Betovsky, não falo de um patch amador. É que eu não entendo a vossa escala para medir a credibilidade/qualidade dos pessoas/produtos. Eu falei da patch de um senhor chamado Greg Stein. E caso não saibas, e tenho o maior gosto em informar-te, este senhor, é um director da Apache Software Foundation. Se (ainda) achas (e reforço o "se") que isso não significa muito, ele é membro da Python Software Foundation, tendo chegado a ser director de 2001 a 2002, tendo sido um "maintainer" da implementação CPython. Posto isto, podemos tirar duas conclusões:
- ou ele é um nabo do carago, é um programador da treta e enganou todas as empresas onde trabalhou, os milhares de pessoas que ouviram as suas palestras e o camandro;
- ou então é uma pessoa que percebe (percebia?) da implementação CPython e que o seu trabalho não foi um Hello World feito assim às 3 pancadas.
Para responder-te à parte dos repositórios... Será que existe a necessidade de colocar algo que não funciona (devidamente) neles?

Ao invés de agora, que em dual core corre MUITO MAIS LENTO que num core.
Epá, mas é necessário eu estar a repetir-me? É MUITO MAIS LENTO em dois cores, porque se existem duas realidades (e para ser mais fácil, deixa-me pôr isto matematicamente, onde
t é o runtime):
Without GIL: Single Core corre em
2*t e em Dual Core corre em
tWith GIL: Single Core corre em
t e em Dual Core corre em
2*tOra bem, qual das duas escolher?

Sem o GIL, o DUAL CORE corre no mesmo tempo que o SINGLE CORE com GIL. Então se com menos um CORE podemos ter a mesma performance, é óbvio que se deve escolher a melhor relação performance/cores. Mas espera... Com o GIL, o DUAL CORE corre no DOBRO (ou mais) do tempo que o SINGLE CORE...
GIL 1 - 1 NoGIL
A solução está que com DUAL CORE, nós podemos utilizar apenas um CORE e ter a performance normal com GIL, mas se tivermos apenas UM CORE (como ainda existe muita gente que tem, inclusive eu até há pouco tempo) não podemos ter a performance
t sem GIL, porque sem GIL, só os DUAL CORE têm performance normal.

Sim, de facto ter as threads a correr só sobre 1 core quando tem-se mais não traz vantagem nenhuma....
Hmm... Para as pessoas que querem pôr os seus ALL-MIGHTY MULTI-GOOGOL-CORES a funcionar, o GvR deu uma solução que é usar processos...
Só dei exemplo dessas duas porque tem uma data de nascimento muito similar. Mas podes usar outra linguagem qualquer. Perl por exemplo. Se o factor utilização tens Java por exemplo.
Não percebi.

Mesmo assim, o Python lançou agora o 3.0, era a altura ideal para fazer uma alteração ao funcionamento das entranhas.
O GvR é o que manda... E se fores ler os objectivos do Py3k, não fala em GILs nem outras coisas, ele delineou (em conjunto com o resto da equipa de developers) que o Py3k teria outros objectivos...
Certo. Então e nos últimos 5-6 anos ninguém se lembrou da questão? Ou lembraram mas o GvR cagou d'alto?
Podia ter sido há 5-6, 10 anos. Se não existe uma BOA solução para o problema, o que se pode fazer?