Requests: Considere a inclusão de solicitações na biblioteca padrão do Python 3.5

Sim, porque simplifica todo o processo e não sacrifica a performance. Então sim.

• Que tipo de impacto isso teria na capacidade das Solicitações de evoluir e crescer?
• A frequência de lançamento de Requests coincide com a de Python? Uma grande diferença aqui pode ser uma boa indicação de que stdlib não é o local certo para solicitações.

Vamos CC para algumas pessoas cujas opiniões nos importamos fortemente:

@shazow @kevinburke @dstufft @alex @ sigmavirus24

O que aconteceu com "a biblioteca padrão é onde as coisas vão morrer"?

A questão da cadência de liberação é boa; Eu ficaria preocupado em perder a capacidade do pedido de evoluir livremente. Dito isso, talvez uma biblioteca central de solicitações seja uma boa opção.

O valor de minhas 2 $ CURRENCY:

Eu não gostaria de fazer isso. Acho que estar fora da biblioteca padrão nos deu a liberdade de fazer escolhas que beneficiam nossos usuários, sem ficar preso às políticas do desenvolvedor principal para suporte e lançamento de versão. Isso nos permite discordar respeitosamente das prioridades do core dev. E permite-nos tomar decisões ideológicas, que são a força vital deste projeto há mais de três anos.

Eu acho que a realidade é que, se este módulo entrar na biblioteca padrão, a equipe principal atual sairá dele. Certamente, tenho pouco interesse em segui-lo no atoleiro que é o core dev. O mais provável para administrar solicitações no stdlib é @ sigmavirus24 , e ele é apenas um homem. Essa perda de direção inevitavelmente levará a uma erosão da interface da biblioteca ao longo do tempo, e acho que seria uma coisa trágica.

A única coisa que estar na biblioteca padrão nos dá é nosso tempo de volta. Esse é um bom motivo para colocá-lo lá, se é disso que você acha que ele precisa, mas não acho que devemos fingir que isso tornará a biblioteca ou o ecossistema Python melhor.

Eu não acho que você realmente _pode_ adicionar solicitações ao stdlib sem primeiro adicionar chardet e urllib3 ou remover sua dependência deles. Há também uma coisa em que o Python não quer enviar um pacote CA, então você precisa modificá-lo para que ele use o pacote da plataforma do sistema como o Python faz naturalmente agora.

Além disso, não tenho certeza. Certamente tornaria mais fácil obter solicitações, no entanto, parte do meu trabalho no pip é basicamente torná-lo fácil de obter coisas como solicitações sem precisar adicioná-lo ao stdlib. Além disso, também é um pouco confuso ter várias maneiras de fazer solicitações HTTP no stdlib do Python. A unificação de urllib e urllib2 foi uma coisa boa no stdlib do Python e também não acho que adicioná-la novamente com urllib.request e "solicitações" seja uma boa ideia. Finalmente, não acho que ajudaria muitas pessoas, isso só iria para 3.5+, então quem quiser usar solicitações teria que usar a versão que está no PyPI ou tornar 3.5 sua versão mínima suportada do Python, o que eu não Acho que é algo realista que aconteça em um futuro próximo.

Embora eu ache que ter Requests na biblioteca padrão ajudaria novos usuários, não sei se ajudaria a comunidade Python como um todo. Usuários experientes sabem usar Requests e sabem como instalá-lo.

Eu ficaria especialmente preocupado com o efeito inibidor que isso teria sobre o novo desenvolvimento, já que outros estariam relutantes em contribuir, sabendo que eles não veriam suas mudanças contribuídas em uma versão facilmente utilizável por muito tempo.

E quanto ao meio-termo para fazer as distribuições Python serem enviadas com ele instalado por padrão?

Não, não iria.

request é absolutamente inadequado para inclusão de stdlib pelas muitas razões apresentadas antes de mim. A dependência urllib3 sozinha é um obstáculo completo; não queremos que ele morra no stdlib.

O que _seria_ útil é adicionar algo _básico_ e semelhante a solicitações construídas sobre os recursos http atuais do stdlib que permite aos usuários fazer solicitações get / post simples para https sem praticar magia de sangue.

Também lembre-se de que ele seria adicionado apenas ao Python 3. :) (e não anterior ao Python 3.6).

Você está cansado de mantê-lo, Kenneth? ;)

Acho que não podemos nem mesmo começar a discutir essa questão sem que alguém diga o que acontece com httplib, urllib e amigos. Adicionar solicitações sem abordar a complexidade da escolha é, eu acho, pior do que a resposta "ignore o stdlib, apenas use as solicitações". É uma regressão aos dias de urllib, urllib2.

Eu acho que a realidade é que, se este módulo entrar na biblioteca padrão, a equipe principal atual sairá dele. Certamente, tenho pouco interesse em segui-lo no atoleiro que é o core dev. O mais provável para administrar solicitações no stdlib é @ sigmavirus24 , e ele é apenas um homem. Essa perda de direção inevitavelmente levará a uma erosão da interface da biblioteca ao longo do tempo, e acho que seria uma coisa trágica.

Eu iria vagar pelo stdlib para tentar ajudar, mas dado o fato de que exatamente um dos não sei quantos patchsets anteriores eu enviei foi aceito e outro _revisado_ me faz desconfiar de querer me preocupar com esse processo. Eu sei que os desenvolvedores principais são totalmente inundados por coisas mais importantes. Eu também sei que outra pessoa decidiu aleatoriamente que deseja manter o httplib / http, mas eles claramente não são adequados para o trabalho (ainda) e não tenho paciência para trabalhar no httplib quando patches que @Lukasa e eu

Provavelmente acabaria apenas bifurcando solicitações para continuar a usá-lo.

request é absolutamente inadequado para inclusão de stdlib pelas muitas razões apresentadas antes de mim. A dependência urllib3 sozinha é um obstáculo completo; não queremos que ele morra no stdlib.

Sempre foi uma contenção de @kennethreitz (e, portanto, do projeto como um todo) que urllib3 é um detalhe de implementação. Muitos dos maiores recursos das solicitações são manipulados inteiramente pelo urllib3, mas isso não significa que não possam ser reimplementados com cuidado em uma biblioteca verdadeiramente sem dependência.

Quanto à dependência de chardet: não tem sido nada além de uma dor de cabeça para nós (e para mim especificamente). Ele costumava ter bases de código separadas para py2 e py3 até que eu o coloquei em uma única biblioteca de base de código (que só nos últimos meses foi incorporada de volta ao chardet). A biblioteca é lenta e um grande devorador de memória (o que irrita muitas pessoas a ponto de gritar conosco aqui no rastreador de problemas). Não é totalmente preciso e o hardet universal da Mozilla de que foi modelado foi praticamente abandonado pela Mozilla. Portanto, remover o chardet provavelmente seria um resultado positivo.

Sobre se devemos fazer isso ou não, estou francamente despreocupado. O que quer que estivesse no stdlib acabaria sendo solicitações apenas na API. A taxa de adoção do Python 3 é lenta o suficiente para que eu não acho que as pessoas serão significativamente afetadas por isso nos próximos N anos (onde N é o número globalmente desconhecido de anos para 3,5 a ser usado na produção por corporações).

E como eu disse, provavelmente acabaria apenas bifurcando solicitações ou usando urllib3 diretamente nesse ponto.

Discuti longamente isso com Guido outro dia - chardet teria de ser incluído primeiro. Acho que urllib3 e as solicitações podem ser incluídas no pacote http juntos.

No entanto, estou muito inclinado a concordar com @hynek e @dstufft. Talvez os pedidos estejam bem do jeito que estão :)

De qualquer forma, se você tem uma opinião que gostaria de compartilhar, fique à vontade para compartilhá-la aqui (ou a qualquer momento, na verdade).

: brilhos:: bolo:: brilhos:

Além disso, adicionar um novo módulo http ao stdlib sem história de assíncio parece
maluco para mim.

No domingo, 25 de janeiro de 2015 às 13:15:51 Kenneth Reitz [email protected]
escreveu:

De qualquer forma, se você tem uma opinião que gostaria de compartilhar, você é
bem-vindo para compartilhá-lo aqui (ou a qualquer momento, na verdade).

[image:: brilha:] [imagem:: bolo:] [imagem:: brilha:]

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/kennethreitz/requests/issues/2424#issuecomment -71384152
.

Acho que não podemos nem mesmo começar a discutir essa questão sem que alguém diga o que acontece com httplib, urllib e amigos

Este é o meu problema. Acho que o atual estado de coisas confuso deve ser resolvido primeiro.

: +1:: metal:

Só para ficar claro, meu comentário acima sobre a reimplementação do urllib3 para inclusão no stdlib não deve ser considerado levianamente. A quantidade de trabalho necessária para fazer isso seria imensa porque urllib3 é o produto de (provavelmente 10 ou mais) anos de trabalho de desenvolvedor.

Eu também falei com Guido sobre jogar urllib3 no stdlib alguns anos atrás, com a conclusão de que não é uma boa ideia, mas estou bastante neutro sobre isso neste momento.

A API do urllib3 tem sido praticamente estável e completamente compatível com versões anteriores por vários anos. Seu ritmo é possivelmente ainda mais lento do que o do stdlib hoje, com a grande maioria das alterações sendo pequenas correções ou melhorias de segurança (com adições ocasionais de recursos compatíveis com versões anteriores, como tempos limites / novas tentativas granulares). Se alguém realmente quiser tentar colocar urllib3 na biblioteca padrão, não acho que seja uma ideia terrível - simplesmente não é a _melhor_ ideia.

(Não estou falando sobre solicitações, pois ele se move em um ritmo muito diferente com objetivos diferentes do urllib3.)

A melhor ideia, na minha opinião, seria o PSF contratar (ou talvez Kickstart ou algo assim) 1-3 desenvolvedores para construir uma nova biblioteca http em cima do asyncio com suporte a HTTP / 2 com forte inspiração de urllib3, solicitações e hiper. Eu ficaria feliz em ver o máximo possível de código literalmente, mas disposto de maneira consistente, modular e reutilizável. O ideal é direcionar o Python 4 ou algo assim e se livrar de todos os urllibs e httplibs. Espero que isso seja de 6 a 9 meses de trabalho árduo, mas possivelmente mais.

A pior parte sobre o urllib3, que eu adoraria ver substituído se alguém tentar reescrevê-lo de acordo com a sugestão de @ sigmavirus24 , é que ele depende do httplib. A funcionalidade do urllib3 é substancialmente limitada com muito código gasto trabalhando em torno das deficiências do httplib. Porém, se o suporte HTTP / 2 fosse levado a sério nesse objetivo, o escopo da reimplementação do HTTP / 1.1 seria uma fração muito reconfortante do trabalho necessário.

Muitos PyCons atrás, um grupo de nós se encontrou e criou um quadro branco para o layout de uma biblioteca http totalmente nova que refatora todas as peças no arranjo ideal que poderíamos imaginar na época. Eu ficaria feliz em desenterrar essas notas, se alguém tentar fazer isso.

+1 @shazow

Novamente, se alguém tiver tempo e disposição para assumir esse projeto bastante grande, esbocei um projeto de API putativo que pode ser um bom ponto de partida.

Sim, porque a única maneira de permitir solicitações como uma dependência é se estiver em stdlib.

Dito isso, urllib3 contém os recursos que as pessoas realmente desejam, então ter isso em stdlib é o suficiente para mim

Você não usa nenhuma dependência?

@dstufft isso ocorre em projetos que geralmente não funcionam, onde todos não podem se incomodar em descobrir como usar o urllib. (as pessoas não estão adicionando como um dep por causa de ssl / etc geralmente, mas por preguiça)

@dstufft também deps multi-versão basicamente torna difícil usar coisas em bibliotecas. Você provavelmente deseja usar solicitações em seu projeto e, se exigirmos, haverá um grande perigo se ocorrerem alterações de API nas versões.

Embora eu aprecie algumas pessoas que desejam desenvolver dependências sem dependências de outro software que não mudou sua API por anos, este não é o lugar para a discussão.

@ sigmavirus24 eu discordo. as solicitações tiveram sua API alterada no passado. As APIs mudam, é por isso que temos versões, é por isso que as dependências são complexas. Este é um caso perfeito para essa discussão porque as solicitações são uma dependência em muitos projetos.

Se você mudar para o stdlib, a API deve ser estável.

@dcramer a API quebrou exatamente uma vez, em 1.0. As APIs mudam, mas a API dos pedidos também não está planejando nenhuma mudança. A única mudança que tivemos foi adicionar o parâmetro json que não quebra nada. Você pode continuar tentando nos acusar de quebrar demais a API, mas quando projetos como o OpenStack têm requisitos definidos como >=1.2.3 há muito tempo, acho que isso diz muito sobre a estabilidade das solicitações. A API está estável, precisamente porque depois de cortarmos 1.0, rejeitamos todas as novas adições à API (com a óbvia exceção recente de adicionar um json param) e temos sido muito rigorosos em não quebrar a API. Se você não é um consumidor de solicitações, não saberia disso. Portanto, não levo sua ignorância para o lado pessoal.

Além disso, se a API stdlib é supostamente tão estável, explique por que argparse quebrou sua API pública entre Python 3.3 e 3.4?

@ sigmavirus24 agora você está puramente transformando isso em um debate sobre API. Eu estava apenas apontando a razão de não incluí-lo porque ele pode mudar, e todo mundo usa, e todo mundo usa versões diferentes. É ótimo que vocês nunca mudem sua API, mas não tenho desejo ou tempo para segui-la ou presumir que seja verdade.

Você sabe que o Python muda sua API também, muitas vezes na verdade, às vezes de maneiras muito importantes, talvez você já tenha ouvido falar do Python 3?

Bem, estou deixando este debate. Eu deixei minhas opiniões claras. Não tenho certeza do que você está reclamando.

Acho que algumas perguntas importantes a serem respondidas são:

1. Como você gostaria que a documentação padrão (incluindo o tutorial) mudasse? As atuais APIs HTTP da biblioteca padrão datam de uma época em que abstrair os detalhes de protocolos concorrentes (por exemplo, FTP vs HTTP) era considerado uma abordagem desejável. Na década e meia subsequente, a comunidade de desenvolvimento web convergiu para HTTPS + JSON como a abordagem preferencial para interação cliente / servidor de estilo de solicitação / resposta para a maioria dos casos de uso que não sejam a execução de comando remoto (que usa SSH ou Windows RCP), e a API de solicitações é a implementação de cliente padrão de fato desse modelo para aplicativos Python modernos.
2. Você deseja que a API de solicitações seja atualizada de um padrão de fato para um padrão de jure, de forma que seja automaticamente incluída em todos os canais de redistribuição de CPython, seja apoiada por garantias de suporte de longo prazo de CPython (e nossos redistribuidores comerciais), bem como todas as atividades educacionais "somente biblioteca padrão"? (Estes últimos ainda são muito comuns, pois os critérios para uso em ambientes corporativos geralmente incluem suporte e garantias de IP, que o CPython tem, mas as solicitações não. Na situação atual, muitos usuários simplesmente não consideram as solicitações como uma opção porque é muito trabalhoso para eles obterem o credenciamento para uso)
3. Quais outros módulos na biblioteca padrão poderiam ser melhorados com solicitações como a API para construir?
4. Seria melhor manter as próprias solicitações inalteradas como uma implementação independente de versão da API e, em vez disso, adicionar uma nova API inspirada em solicitações à biblioteca padrão, semelhante à forma como Guido abordou o trabalho de padronização ayncio?

No que diz respeito à ideia do trabalho de desenvolvimento gerenciado do PSF, eu seria fortemente contra, já que não temos a infraestrutura de gerenciamento para lidar com esse tipo de coisa. Uma proposta de subsídio sugerindo que o PSF contribua para um esforço de crowdfunding nessa área seria uma história diferente (sem garantias sem uma proposta específica para revisão, mas certamente é uma ideia que estaríamos abertos para discutir).

Observe que alguns fornecedores já podem redistribuir solicitações, mas "eles também fornecem suporte para solicitações?" torna-se uma pergunta separada que devemos fazer a um fornecedor ou provedor de plataforma. Assim, em um contexto de gerenciamento de risco de longo prazo (pense em anos e décadas, em vez de semanas ou meses), dependendo disso, significa que temos que assumir o risco e a responsabilidade de auto-sustento se o upstream ficar entediado e passar para outra coisa, ou então aceitar uma redução potencial no grau de escolha que temos em provedores de plataforma.

Com a biblioteca padrão, geralmente não temos essa preocupação - embora os redistribuidores ocasionalmente quebrem as coisas, em um contexto comercial, os fornecedores que quebram coisas que funcionam no upstream dão a você bastante vantagem para fazer o fornecedor ofensor consertar as coisas.

Ah, uma outra pergunta importante a ser respondida antes de se voluntariar para realmente manter as coisas na biblioteca padrão: você está preparado para aceitar a responsabilidade de enviar software que ajuda a abastecer metade das bolsas de valores do mundo, é uma das linguagens mais populares para infraestrutura corporativa, uma das linguagens mais populares para programação científica (incluindo o uso para planejamento de trajetória em missões espaciais interplanetárias), uma das linguagens mais populares para desenvolvimento da web e uma das linguagens-chave sendo empregadas em novas iniciativas de alfabetização em computadores em instituições educacionais?

Você também está preparado para fazer isso enquanto tem pessoas trabalhando em serviços não críticos onde níveis de confiabilidade muito baixos (muitas vezes menos de 99% de tempo de atividade) são perfeitamente aceitáveis ​​reclamando que seus profundos problemas de confiança são injustificados, e apenas uma questão de política estúpida e obscura que eles não podem se incomodar com isso?

Além disso, uma suposição errada que eu gostaria de corrigir: a grande maioria dos programadores de Python provavelmente nem terá ouvido falar de pip, muito menos de solicitações. Essas são as pessoas que executam scripts no sistema Python em versões de suporte de longo prazo do Linux, as pessoas pelas quais a maioria dos desenvolvedores de código aberto são rápidos em expressar desprezo indizível, sem parar para considerar quais circunstâncias podem estar em jogo para tornar sua abordagem uma boa ideia.

Os tempos do ciclo de adoção nesta comunidade são intrinsecamente medidos em anos. É apenas uma fração cada vez menor da indústria que está executando CI suficientemente rigorosa para ser capaz de ir mais rápido, e a maioria das pessoas nessa fração não está interessada em desacelerar o tempo suficiente para ouvir as preocupações daqueles com grandes faixas de infraestrutura que precisamos gerenciar e modernizar.

Essa parte pós-abismo da curva de adoção de tecnologia é aquela que alcançamos quando dizemos "sim, esta abordagem agora está suficientemente madura para que possamos colocá-la, ou algo baseado nela, na biblioteca padrão para ajudar a torná-la verdadeiramente universal suposição".

Como um exemplo mais concreto de como a bolha do filtro "comunidade de código aberto" pode distorcer nossa perspectiva: Jenkins detém mais de 70% do mercado de implantações de CI corporativas.

Tenha muito, muito cuidado ao confiar em intuições sobre o que "todo mundo sabe", ao basear essa perspectiva em indivíduos e organizações que estão fortemente envolvidos com o código aberto. A grande maioria do desenvolvimento de software ainda é um trabalho personalizado para atender às necessidades de uma organização específica, e a grande maioria das pessoas que fazem isso ainda estão obtendo suas ferramentas e informações de fornecedores comerciais, em vez da comunidade de código aberto.

@dcramer
Não tenho certeza do que você está reclamando.

Linguagem muito apropriada para este debate. Quando contadores legítimos são feitos para sua posição, você usa uma calúnia para rebaixar as mulheres. No entanto, par para o curso. Se movendo,

@ncoghlan

Relativamente ao ponto 1: penso que a documentação seria drasticamente simplificada com pedidos (pedidos semelhantes) no stdlib. Uma das primeiras coisas que faço quando aprendo um novo idioma é descobrir como fazer HTTP. Ter esse destaque é algo de que o guia se beneficiaria de qualquer maneira.

Relativamente ao ponto 2: existe uma diferença entre a API e a biblioteca ser de facto vs. de jure. A API pode ser facilmente fornecida pela biblioteca padrão. Acho que sua preocupação com o suporte seria mais voltada para a inclusão de solicitações (o código).

Com relação aos pontos 3 e 4: Não tenho certeza se isso é algo a ser discutido aqui. Talvez ideias de python fossem melhores.

No que diz respeito à ideia do trabalho de desenvolvimento gerenciado do PSF, eu seria fortemente contra, já que não temos a infraestrutura de gerenciamento para lidar com esse tipo de coisa.

Isso é interessante. Não achei que fosse uma probabilidade, mas seria ótimo ter algo melhor do que http (lib).

Com a biblioteca padrão, geralmente não temos essa preocupação - embora os redistribuidores ocasionalmente quebrem as coisas, em um contexto comercial, os fornecedores que quebram coisas que funcionam no upstream dão a você bastante vantagem para fazer o fornecedor ofensor consertar as coisas.

Não tenho certeza de que tipo de influência você está falando. Eu vi o securepip, venv e outras coisas quebradas pelo Debian e outros redistribuidores no CPython. No entanto, isso é tangencial a esta discussão.

Ah, uma outra pergunta importante a ser respondida antes de se voluntariar para realmente manter as coisas na biblioteca padrão: você está preparado para aceitar a responsabilidade de enviar software que ajuda a abastecer metade das bolsas de valores do mundo, é uma das linguagens mais populares para infraestrutura corporativa, uma das linguagens mais populares para programação científica (incluindo o uso para planejamento de trajetória em missões espaciais interplanetárias), uma das linguagens mais populares para desenvolvimento da web e uma das linguagens-chave sendo empregadas em novas iniciativas de alfabetização em computadores em instituições educacionais?

Como já mencionado, a maioria das pessoas envolvidas atualmente não daria continuidade ao projeto. Eu provavelmente seria a única pessoa, mas dado meu histórico com desenvolvimento upstream de CPython, não seria produtivo deixar esse fardo para os desenvolvedores centrais existentes (e outros futuros).

Essa parte pós-abismo da curva de adoção de tecnologia é aquela que alcançamos quando dizemos "sim, esta abordagem agora está suficientemente madura para que possamos colocá-la, ou algo baseado nela, na biblioteca padrão para ajudar a torná-la verdadeiramente universal suposição".

A realidade é que essas pessoas nunca vão alcançá-lo, não? As pessoas ainda estão executando softwares em Python 2.4 e 2.5. Os balanceadores de carga do F5 ainda oferecem suporte apenas ao Python 2.5. 2.7 estarei em uso provavelmente até o final da minha vida natural (que espero que seja bem longa). Essas são realmente as pessoas que essa decisão afetará mais fortemente? Essas mesmas pessoas que você descreve podem nunca dar o salto para o Python 3. E, atualmente, ainda é um _pelo_. Talvez quando eles decidirem considerá-lo, o Python 3.8, 3.9 ou 4.2 já terá sido lançado e será muito menos incômodo para eles.

Certo, meu ponto principal é que o objetivo da inclusão de biblioteca padrão é _muito_ diferente daquele da tarefa mais comum de fornecer uma biblioteca de código aberto para uso por outros desenvolvedores de código aberto. Se a equipe de solicitações optar por continuar fornecendo apenas a biblioteca mantida de forma independente (um serviço comunitário pelo qual sou imensamente grato, vocês fazem um ótimo trabalho!) E não apoiarem a padronização da API, estaremos contando em redistribuidores como RHEL / Fedora / CentOS, Debian / Ubuntu, ActiveState, Enthought e Continuum Analytics para pegar o módulo e padronizá-lo _de qualquer forma_, de modo que as pessoas possam presumir que sempre estará disponível (ou pelo menos com frequência suficiente para que estejam feliz contando com a API em scripts de arquivo único que não são totalmente empacotados com declarações de dependência apropriadas). No entanto, a maior parte da documentação introdutória provavelmente ainda orientará as pessoas a fazer HTTP da forma de biblioteca padrão, então se as pessoas aprenderão "HTTP para Python, edição 2001" ou "HTTP para Python, edição 2015" dependerá se eles aprenderam a partir de um fonte "somente biblioteca padrão", ou que englobe módulos de terceiros recomendados.

Como acontece com virtualenv e PEP 405, ou Twisted + Tornado vs asyncio, ou ipaddr vs ipaddress, não acredito que faça sentido incluir o _requests propriamente dito_ na biblioteca padrão. Em vez disso, acho que faz mais sentido apoiar a inclusão de uma API _inspired_ de solicitações que deixa de fora todo o código de compatibilidade de versão cruzada, o pacote de certificados, etc, etc, e simplesmente traz as APIs padrão e documentação para lidar com solicitações HTTP autenticadas até 2015 padrões. Então, em 2030, estaremos reclamando sobre o quão arcaico é o design da API _requests_ para os padrões de 2030 ("HTTP? Quem mais usa isso?!?!"), Mas tudo bem, é apenas como esses ciclos funcionam (até o primeiro AJAX e então veio o JSON, XML-RPC era o rei da colina). Se você tirar 5 anos do projeto de uma API antes que as pessoas comecem a reclamar de que ela está datada, você está se saindo muito bem, 10 é impressionante e 15 é realmente espetacular.

A principal coisa necessária para iniciar esse processo é alguém suficientemente motivado pela ideia de ter a API de solicitações disponível em todos os lugares para defender o esforço de padronização, fazer o trabalho de implementação e ter como objetivo se comprometer com pelo menos os primeiros anos de manutenção stdlib. A alternativa é continuar a depender fortemente de redistribuidores para alcançar desenvolvedores que não desejam e / ou não são capazes de baixar e executar código arbitrário da Internet (uma categoria que inclui todos em qualquer setor com requisitos de devida diligência regulatória estritos, bem como qualquer pessoa trabalhar para outras organizações com um apetite de risco igualmente baixo).

Com relação a alguns dos outros pontos, nossa vantagem atual com o Debian é relativamente fraca, enquanto a vantagem é melhor com redistribuição com suporte comercial, onde clientes pagantes podem reclamar diretamente sobre coisas que estão sendo quebradas em relação às expectativas estabelecidas por nós como uma comunidade de desenvolvimento upstream.

Em termos de ciclos de atualização, uma das principais coisas que a padronização upstream (mesmo no Python 3) transmite é o consenso da comunidade. Com isso, as bibliotecas que são "backports" dos recursos do Python 3 tornam-se muito mais fáceis de justificar o empacotamento com o Python 2. Eu pessoalmente ainda gostaria de ver uma versão sumo do Python 2 que faz exatamente esse empacotamento (unittest2, subprocess32, enum34, contextlib2 , trollius, etc), mas essa é uma batalha política totalmente separada por si só, especialmente em termos de persuadir as pessoas de que o interesse e os recursos para manter tal distribuição de sumô independente de redistribuidor até 2020 estão realmente disponíveis.

@dcramer obrigado por nos dar seu tempo - é muito apreciado: coração:

@ sigmavirus24 está tudo bem :)

Eu não tenho muito a adicionar na frente de inclusão stdlib, exceto,
seria legal olhar para alguns PEPs ou tópicos ou conversas sobre o que deve ser feito
no stdlib do Python, e talvez olhar para o ano passado ou algo assim
desenvolvimento da perspectiva de "como lidar com este problema
diferente se fosse um módulo da biblioteca padrão ".

Uma vez que este pode se tornar o tópico de fato, as pessoas olham quando dizem
"o que devemos adicionar / alterar ao considerar a adição de solicitações ao stdlib",
Eu gostaria de dar outro grito para atualizar a hierarquia de exceção. eu
geralmente tem duas perguntas quando uma solicitação falha - a) Quais são as
implicações? eb) Posso repetir a solicitação com segurança?
Uma falha de pesquisa de DNS e um tubo quebrado têm implicações muito diferentes,
mas as solicitações atualmente agrupam ambos como ConnectionError. Eu detalhei alguns
do trabalho envolvido aqui:
https://gist.github.com/kevinburke/b98e053a4bf9835c67bb

Fico feliz em discutir mais com pessoas interessadas.

Kevin burke
telefone: 925.271.7005 | twentymilliseconds.com

No domingo, 25 de janeiro de 2015 às 20h15, ncoghlan [email protected] escreveu:

Como um exemplo mais concreto de como o filtro "comunidade de código aberto"
bolha pode distorcer nossa perspectiva: Jenkins detém mais de 70% do mercado
em implantações de CI corporativas.

Seja muito, muito cauteloso ao confiar em intuições sobre o que "todos
sabe ", quando você baseia essa perspectiva em indivíduos e
organizações que estão fortemente envolvidas com o código aberto. A grande maioria
de desenvolvimento de software ainda é um trabalho personalizado para atender às necessidades de um
organização particular, e a grande maioria das pessoas que fazem isso são
ainda obtendo suas ferramentas e informações de fornecedores comerciais, em vez
do que a comunidade de código aberto.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/kennethreitz/requests/issues/2424#issuecomment -71413074
.

FWIW, acho que o texto em http://docs.python-requests.org/en/latest/dev/philosophy/ ,

Essentially, the standard library is where a library goes to die.
It is appropriate for a module to be included when active 
development is no longer necessary.

pode ser mal interpretado. Para mim, parece uma atitude pejorativa em relação à Biblioteca Padrão, que obviamente não consiste em bibliotecas mortas. Fiquei irritado e evitei usar pedidos, até chegar a esta página, que é uma discussão interessante e muito melhor do que o texto acima.