No caminho para o núcleo do Python

Olá Habr! Apresento a você a tradução do artigo Toward a “Kernel Python” de Glyph Lefkowitz (criador do framework Twisted).

Mais detalhes - sob o corte.

A mágica de minimizar a biblioteca padrão

Sob a influência do discurso de Amber Brown no mês passado no Python Language Summit (referindo-se ao relatório de maio "As baterias estão gastas, mas estão vazando" - comentário do tradutor) Christian Hymes continuou seu trabalho para reduzir a biblioteca padrão do Python e criou uma proposta de remoção explícita do PEP 594 fragmentos obsoletos e sem suporte.

O advento do PEP 594 (“Remoção de baterias gastas da biblioteca padrão”) é uma ótima notícia para os pitonistas, especialmente aqueles que apóiam a biblioteca padrão e agora terão uma frente de trabalho menor. Um breve tour pela galeria do PEP de módulos obsoletos ou baseados em remoção fala por si (os módulos sunau, xdrlib e chunk são meus favoritos pessoais). A biblioteca padrão do Python contém muitos módulos úteis, no entanto, também inclui uma necrópole de código real, um monumento imponente de fragmentos obsoletos que ameaçam enterrar seus desenvolvedores a qualquer momento.

No entanto, acredito que a abordagem incorreta pode ser implementada nesta sentença do PEP. Atualmente, a biblioteca padrão é suportada em conjunto com os desenvolvedores do CPython. Grandes pedaços foram deixados na vaga esperança de que algum dia beneficiaria alguém. No PEP acima mencionado, esse princípio pode ser observado ao proteger o módulo colorsys. Por que não removê-lo? Resposta: “Este módulo é necessário para converter cores CSS entre sistemas de coordenadas (RGB, YIQ, HSL e HSV). [Ele] não impõe custos adicionais ao desenvolvimento principal. ”

Houve momentos em que o acesso à Internet era limitado e talvez fosse uma boa ideia pré-carregar o Python com uma tonelada de material, mas hoje em dia os módulos necessários para converter cores entre diferentes sistemas de coordenadas estão a um passo do comando pip install.

Por que você não considerou minha solicitação de pool?

Então, vejamos esta afirmação: pequenos módulos como o colorsys impõem "um custo extra ao desenvolvimento do núcleo"?

É o suficiente para os principais desenvolvedores que eles estão tentando manter uma base enorme e antiga de código C, que é o próprio CPython. Como Marietta Viggia disse em seu discurso no North Bay Python, a pergunta mais comum feita pelos desenvolvedores do kernel é: "Por que você não olhou para a minha solicitação de pool?" E qual é a resposta? É mais fácil ignorar essas solicitações de pool. É isso que significa ser um desenvolvedor de kernel!

Alguém pode perguntar: Twisted tem o mesmo problema? O Twisted também é uma grande coleção de módulos fracamente acoplados; um tipo de biblioteca padrão para rede. São todos esses clientes e servidores para SSH, IMAP, HTTP, TLS, etc. etc. tentando espremer tudo em um pacote?

Forçado a responder: sim . Twisted é monolítico porque vem do mesmo período histórico do CPython, quando a instalação do componente era realmente complicada. Portanto, simpatizo com a posição do CPython.

Idealmente, em algum momento, cada subprojeto no Twisted deve se tornar um projeto separado com seu próprio repositório, integração contínua (CI), site e, é claro, com seus próprios desenvolvedores mais focados. Já estamos lenta mas seguramente compartilhando projetos em que uma fronteira natural pode ser traçada. Alguns dos pontos iniciados no Twisted como constantes e incrementais são separados, adiados e caminho do arquivo estão no processo de separação. Outros projetos, como klein e treq, continuam vivendo separadamente. Faremos mais quando descobrirmos como reduzir os custos de configuração e suporte à integração contínua e como liberar a infraestrutura para cada um deles.

Mas a natureza monolítica de Twisted é o problema mais urgente ou até mais sério para o projeto? Vamos apreciar isso.

No momento da redação deste artigo, o Twisted tinha 5 solicitações de pool pendentes não resolvidas em linha. O tempo médio gasto na consideração de um ticket é, grosso modo, quatro dias e meio. O ticket mais antigo da fila tem data de 22 de abril, o que significa que passaram menos de 2 meses desde que a solicitação de pool não revisada mais antiga foi enviada.

É sempre difícil encontrar desenvolvedores e tempo suficientes para responder às solicitações de pool. Às vezes, parece que ainda recebemos com muita frequência a pergunta "Por que você não está considerando minha solicitação de piscina?" Nem sempre fazemos isso perfeitamente, mas geralmente conseguimos; a fila varia entre 0 e 25 ou mais no mês mais azarado.

E o núcleo do CPython comparado a esses números?

Tendo visitado o github , você pode ver que 429 ingressos estão aguardando consideração no momento. O mais antigo deles é esperado a partir de 2 de fevereiro de 2018, ou seja, quase 500 dias.

Quantos problemas com o intérprete e quantos problemas com a biblioteca stdlib? Obviamente, uma revisão pendente é um problema, mas a remoção do stdlib ajudará?

Para uma avaliação rápida e não científica, observei a primeira página (mais antiga) de solicitações de pool. Na minha avaliação subjetiva, das 25 solicitações de pool, 14 foram associadas à biblioteca padrão, 10 ao núcleo da linguagem ou ao código do intérprete e uma foi associada a um pequeno problema de documentação. Com base nessa proporção, arriscaria sugerir que cerca de metade das solicitações de pool não revisadas estão associadas ao código da biblioteca padrão.

Portanto, a primeira razão pela qual a equipe principal do CPython precisa parar de dar suporte à biblioteca padrão é porque eles literalmente não têm capacidade física para dar suporte à biblioteca padrão. Ou, em outras palavras, eles não a apoiam , e resta apenas admitir e começar a compartilhar o trabalho.

É fato que nenhuma das solicitações de pool aberto do CPython está associada ao módulo colorsys. De fato, ele não impõe custos ao desenvolvimento do kernel. O próprio desenvolvimento do kernel impõe esses custos. Se eu quisesse atualizar o módulo colorsys para acompanhar os horários (talvez para ter um objeto Color, talvez para suportar modelos de cores inteiros), provavelmente teria que esperar 500 dias ou mais.

Como resultado de tudo isso, é mais difícil alterar o código na biblioteca padrão, o que leva a um menor interesse dos usuários em contribuir. Versões pouco frequentes do CPython também atrasam o desenvolvimento da biblioteca e reduzem os benefícios do feedback do usuário. Não é coincidência que quase todos os módulos da biblioteca padrão tenham suportado ativamente alternativas de terceiros, e isso não é culpa dos desenvolvedores do stdlib. Todo o processo é aguçado para estagnar todos os módulos stdlib, exceto os mais usados.

Novos ambientes, novos requisitos

Talvez ainda mais importante seja que vincular o CPython à biblioteca padrão coloque o próprio CPython em uma posição privilegiada em comparação com outras implementações de linguagem.

O podcast após o podcast , o podcast após o relatório, nos diz que, para continuar o sucesso e o desenvolvimento do Python, você precisa crescer em novas áreas: especialmente no front-end, além de clientes móveis, sistemas embarcados e jogos de console.

Esses ambientes requerem uma ou duas condições:

• um tempo de execução completamente diferente (consulte Brython ou MicroPython )
• versão simplificada modificada da biblioteca padrão.

Em todos esses casos, o obstáculo é a definição de módulos que devem ser removidos da biblioteca padrão. Eles precisam ser encontrados por tentativa e erro; Primeiro de tudo, o processo é completamente diferente do processo de determinação de dependência padrão em um aplicativo Python. Não há nenhuma declaração install_requires no setup.py relatando que a biblioteca usa um módulo do stdlib que o tempo de execução do Python de destino pode ignorar devido a limitações de espaço.

Um problema pode ocorrer mesmo se tudo o que usamos for Python padrão em uma instalação do Linux. Até as distribuições Linux para servidores e computadores de mesa têm a mesma necessidade de um pacote menor do kernel Python, portanto a biblioteca padrão já está bastante truncada. Isso pode não atender aos requisitos do código Python e, como resultado, levar a erros quando mesmo a instalação do pip não funcionará .

Leve tudo embora

“E a suposição de que você precisa limpar um pouco todos os dias? Embora pareça convincente, não se deixe enganar. A razão pela qual lhe parece que a limpeza nunca termina é justamente porque você está limpando um pouco. [...] O principal segredo do sucesso é este: se você o remover de uma só vez, e não gradualmente, poderá mudar permanentemente seus hábitos de pensamento e vida ”

Marie Kondo, Limpeza Mágica. A arte japonesa de restaurar a ordem em casa e na vida "(p. 15-16)

Embora a redução gradual da biblioteca padrão seja um passo na direção certa, apenas as mudanças graduais não são suficientes. Como diz Marie Kondo, se você realmente deseja colocar as coisas em ordem, o primeiro passo é tirar tudo da vista para realmente ver tudo e, em seguida, retornar apenas o necessário.

Chegou a hora de homenagear aqueles módulos que não são mais encorajadores e enviá-los por um longo caminho.
Precisamos de uma versão do Python que contenha apenas o mínimo mais necessário para que todas as implementações possam ser consistentes e para que os aplicativos (mesmo aqueles que funcionam em navegadores da web ou microcontroladores) possam simplesmente declarar seus requisitos em requirements.txt.

Em alguns ambientes de negócios, a idéia de uma enorme biblioteca padrão parece atraente porque a adição de dependências no requirements.txt é burocrática; no entanto, a “biblioteca padrão” nesses ambientes possui limites puramente arbitrários.

Ainda pode ser uma boa idéia fornecer algumas das distribuições binárias do CPython (possivelmente até as oficiais) com uma ampla seleção de módulos do PyPI. De fato, mesmo para tarefas comuns, é necessária uma certa quantidade da biblioteca stdlib, cujo pip precisa instalar outros módulos necessários.

Agora há uma situação em que o pip é distribuído junto com o Python, mas não é desenvolvido no repositório CPython. Parte do que o instalador padrão do Python vem é desenvolvida no repositório CPython, parte vem em um pacote separado para o intérprete.

Para usar o Linux, precisamos de mídia inicializável com uma enorme variedade de programas adicionais. Mas isso não significa que o próprio kernel do Linux esteja localizado em um repositório gigante, no qual centenas de aplicativos necessários para um servidor Linux em funcionamento são desenvolvidos por uma equipe. O kernel Linux é extremamente valioso, mas os sistemas operacionais que o utilizam são criados a partir de uma combinação do kernel Linux e de uma ampla variedade de bibliotecas e programas desenvolvidos separadamente.

Conclusão

A filosofia "baterias incluídas" era ideal para a sua criação; como um foguete de reforço, entregou o Python ao público da programação. No entanto, à medida que os ecossistemas de código aberto e os pacotes Python amadurecem, essa estratégia se torna obsoleta e, como qualquer acelerador, devemos deixá-la retornar ao terreno para que não nos arraste de volta.

Novos tempos de execução do Python, novas tarefas de implantação e novos públicos de desenvolvedores oferecem à comunidade Python enormes oportunidades para alcançar novos patamares.

Mas, para conseguir isso, precisamos de um novo núcleo Python mais compacto e sem sobrecarga. Precisamos sacudir toda a biblioteca padrão, deixando apenas as menores peças necessárias para podermos dizer: isso é realmente necessário, mas é bom ter.

Espero ter convencido pelo menos alguns de vocês de que núcleo Python precisamos.

E agora: quem quer escrever PEP ?