Requests: Considérez l'inclusion des requêtes dans la bibliothèque standard de Python 3.5

Oui, car cela simplifie l'ensemble du processus et ne sacrifie pas les performances. Donc oui.

• Quel type d'impact cela aurait-il sur la capacité de Requests à évoluer et à croître ?
• La fréquence de publication de Requests correspond-elle à celle de Python ? Une grande différence ici pourrait être une bonne indication que stdlib n'est pas la bonne maison pour les requêtes.

Mettons en CC certaines personnes dont les opinions nous tiennent à cœur :

@shazow @kevinburke @dstufft @alex @sigmavirus24

Qu'est-il arrivé à « la bibliothèque standard est l'endroit où les choses vont mourir » ?

La question de la cadence de sortie est bonne ; Je serais inquiet de perdre la capacité de la demande à évoluer librement. Cela dit, peut-être qu'une bibliothèque de base de requêtes serait un bon choix.

La valeur de mes 2 $ CURRENCY :

Je serais peu enclin à le faire. Je pense que le fait d'être en dehors de la bibliothèque standard nous a donné la liberté de faire des choix qui profitent à nos utilisateurs sans être bloqués par les politiques de développement de base pour la prise en charge et la publication des versions. Cela nous permet de ne pas être d'accord avec les priorités du core dev. Et cela nous permet de prendre des décisions qui sont idéologiques, ce qui est la pierre angulaire de ce projet depuis plus de trois ans.

Je pense que la réalité est que si ce module entre dans la bibliothèque standard, l'équipe de base actuelle en sortira. J'ai certainement peu d'intérêt à le suivre dans le bourbier qu'est le développement de base. Le plus susceptible de gérer les demandes dans la stdlib est @sigmavirus24 , et ce n'est qu'un homme. Cette perte de direction entraînera inévitablement une érosion de l'interface de la bibliothèque au fil du temps, et je pense que ce serait une chose tragique.

La seule chose que nous donne le fait d'être dans la bibliothèque standard, c'est notre temps en arrière. C'est une bonne raison de le mettre là, si c'est ce dont vous pensez qu'il a besoin, mais je ne pense pas que nous devrions prétendre que cela améliorera la bibliothèque ou l'écosystème Python.

Je ne pense pas que vous puissiez réellement ajouter des requêtes à la stdlib sans d'abord ajouter chardet et urllib3 ou supprimer votre dépendance à leur égard. Il y a aussi la chose où Python ne veut pas expédier un CA Bundle, vous devez donc le modifier pour qu'il utilise le bundle de plate-forme système comme Python le fait naturellement maintenant.

A part ça, je ne suis pas sûr. Cela faciliterait certainement l'obtention de demandes, mais une partie de mon travail sur pip consiste essentiellement à le rendre facile d'obtenir des choses comme des demandes sans avoir besoin de l'ajouter à la stdlib. En plus de cela, il est également quelque peu déroutant d'avoir plusieurs façons de faire des requêtes HTTP dans la stdlib Python. L'unification de urllib et urllib2 était une bonne chose dans la stdlib Python et je ne pense pas que le rajouter avec urllib.request et "requests" soit une bonne idée non plus. Enfin, je ne pense pas que cela aiderait vraiment beaucoup de gens, cela n'irait que dans 3.5+, donc toute personne souhaitant utiliser des requêtes devrait soit utiliser la version qui est sur PyPI, soit faire de 3.5 sa version Python minimale prise en charge, ce que je ne ' Je pense que c'est une chose réaliste qui se produira dans un avenir proche.

Bien que je pense que le fait d'avoir des requêtes dans la bibliothèque standard aiderait les nouveaux utilisateurs, je ne sais pas si cela aiderait la communauté Python dans son ensemble. Les utilisateurs expérimentés savent utiliser Requests et savent comment l'installer.

Je serais particulièrement préoccupé par l'effet paralysant que cela aurait sur les nouveaux développements, car d'autres seraient peu enclins à contribuer, sachant qu'ils ne verraient pas leurs modifications apportées dans une version facilement utilisable pendant longtemps.

Qu'en est-il du juste milieu pour faire en sorte que les distributions Python soient livrées avec son installation par défaut ?

Non, ça ne le ferait pas.

demandes est absolument inadapté à l'inclusion de stdlib pour les nombreuses raisons indiquées avant moi. La dépendance urllib3 à elle seule est un obstacle complet ; nous ne voulons pas qu'il meure dans la stdlib.

Ce qui _serait_ utile, c'est d'ajouter quelque chose de _basique_ et similaire aux requêtes construites sur les ressources http actuelles de stdlib qui permet aux utilisateurs de faire des requêtes simples get/post sur https sans pratiquer la magie du sang.

Rappel également aimable qu'il serait ajouté à Python 3 uniquement. :) (et pas avant Python 3.6).

Êtes-vous fatigué de l'entretenir Kenneth? ;)

Je ne pense pas que nous puissions même commencer à discuter de cette question sans que quelqu'un dise ce que deviennent httplib, urllib et ses amis. Ajouter des requêtes sans aborder la complexité du choix est, je pense, pire que la réponse "ignorez la stdlib, utilisez simplement les requêtes". C'est une régression à l'époque d'urllib, urllib2.

Je pense que la réalité est que si ce module entre dans la bibliothèque standard, l'équipe de base actuelle en sortira. J'ai certainement peu d'intérêt à le suivre dans le bourbier qu'est le développement de base. Le plus susceptible de gérer les demandes dans la stdlib est @sigmavirus24 , et ce n'est qu'un homme. Cette perte de direction entraînera inévitablement une érosion de l'interface de la bibliothèque au fil du temps, et je pense que ce serait une chose tragique.

Je me promènerais dans la stdlib pour essayer d'aider, mais étant donné qu'exactement l'un des ensembles de correctifs que j'ai soumis précédemment a été accepté et qu'un autre _revu_ me fait craindre de vouloir m'embêter avec ce processus. Je sais que les développeurs principaux sont entièrement submergés par des choses plus importantes. Je sais aussi que quelqu'un d'autre a décidé au hasard qu'il voulait maintenir httplib/http mais il est clair qu'il n'est pas (encore) adapté au travail et je n'ai pas la patience de travailler sur httplib lorsque des correctifs que @Lukasa et moi sommes assis autour, non révisés et indifférents (quand ils résolvent des problèmes urgents avec la bibliothèque).

Je finirais probablement par faire des demandes pour continuer à l'utiliser.

demandes est absolument inadapté à l'inclusion de stdlib pour les nombreuses raisons indiquées avant moi. La dépendance urllib3 à elle seule est un obstacle complet ; nous ne voulons pas qu'il meure dans la stdlib.

@kennethreitz (et par conséquent, le projet dans son ensemble) a toujours soutenu que urllib3 est un détail d'implémentation. La plupart des fonctionnalités les plus importantes des requêtes sont entièrement gérées par urllib3, mais cela ne signifie pas qu'elles ne peuvent pas être réimplémentées avec soin dans une bibliothèque véritablement sans dépendance.

Concernant la dépendance au chardet : ça n'a été qu'un casse-tête pour nous (et pour moi en particulier). Il y avait des bases de code séparées pour py2 et py3 jusqu'à ce que je l'aie dans une seule bibliothèque de base de code (qui n'a été fusionnée qu'au cours des derniers mois dans chardet proprement dit). La bibliothèque est lente et gourmande en mémoire (ce qui énerve de nombreuses personnes au point de nous crier dessus ici sur le suivi des problèmes). Ce n'est pas tout à fait exact et la charte universelle de Mozilla sur laquelle il s'inspire a pratiquement été abandonnée par Mozilla. Donc supprimer chardet serait probablement un net positif de toute façon.

Quant à savoir si nous devrions le faire ou non, je suis franchement indifférent. Tout ce qui serait dans la stdlib finirait par être des requêtes dans l'API uniquement. Le taux d'adoption de Python 3 est suffisamment lent pour que je ne pense pas que les gens en seront affectés de manière significative au cours des N prochaines années (où N est le nombre d'années globalement inconnu pour 3,5 à utiliser dans la production par les entreprises).

Et comme je l'ai dit, je finirais probablement par bifurquer des requêtes ou utiliser urllib3 directement à ce stade.

J'en ai discuté longuement avec Guido l'autre jour — il faudrait d'abord inclure chardet. Je pense que urllib3 et les requêtes pourraient être inclus dans le package http ensemble.

Cependant, je suis très enclin à être d'accord avec @hynek et @dstufft. Peut-être que les demandes sont bien telles qu'elles sont :)

Quoi qu'il en soit, si vous avez une opinion que vous aimeriez partager, vous pouvez la partager ici (ou à tout moment vraiment).

:paillettes: :gâteau: :paillettes:

De plus, l'ajout d'un nouveau module http à la stdlib sans asyncio-story semble
dingue pour moi.

Le dimanche 25 janvier 2015 à 13:15:51 Kenneth Reitz [email protected]
a écrit:

Quoi qu'il en soit, si vous avez une opinion que vous aimeriez partager, vous êtes
bienvenue à le partager ici (ou à tout moment vraiment).

[image: :sparkles:] [image: :cake:] [image: :sparkles:]

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/kennethreitz/requests/issues/2424#issuecomment-71384152
.

Je ne pense pas que nous puissions même commencer à discuter de cette question sans que quelqu'un dise ce que deviennent httplib, urllib et amis

C'est mon problème. Je pense qu'il faut d'abord régler la situation actuelle déroutante.

:+1: :métal:

Juste pour être clair, mon commentaire ci-dessus sur la réimplémentation de urllib3 pour l'inclusion dans la stdlib ne doit pas être pris à la légère. La quantité de travail nécessaire pour faire cela serait immense car urllib3 est le produit de (probablement 10 ou plus) années de travail de développeur.

J'ai moi aussi parlé avec Guido du lancement de urllib3 dans la stdlib il y a quelques années avec la conclusion que ce n'est pas une bonne idée, mais je suis assez neutre à ce sujet à ce stade.

L'API d'urllib3 est globalement stable et à peu près complètement rétrocompatible depuis plusieurs années maintenant. Son rythme est peut-être encore plus lent que celui de la stdlib aujourd'hui, la grande majorité des modifications étant des correctifs mineurs ou des améliorations de sécurité (avec des ajouts occasionnels de fonctionnalités rétrocompatibles comme des délais d'attente/réessais granulaires). Si quelqu'un voulait vraiment essayer d'intégrer urllib3 dans la bibliothèque standard, je ne pense pas que ce soit une mauvaise idée—ce n'est tout simplement pas la _meilleure_ idée.

(Je ne parle pas pour les demandes, car il évolue à un rythme très différent avec des objectifs différents de urllib3.)

La meilleure idée, à mon avis, serait que la PSF embauche (ou peut-être Kickstart ou quelque chose du genre) 1-3 développeurs pour créer une toute nouvelle bibliothèque http au-dessus d'asyncio avec le support HTTP/2 avec une forte inspiration de urllib3, requêtes , et hyper. Je serais heureux de voir autant de code pris textuellement que possible mais présenté de manière cohérente, modulaire et réutilisable. Idéalement, ciblez Python 4 ou quelque chose du genre, et débarrassez-vous de toutes les urllibs et httplibs. Je m'attends à ce que ce soit 6 à 9 mois de travail acharné, mais peut-être plus.

Le pire avec urllib3, que j'aimerais voir remplacé si quelqu'un tente de le réécrire selon la suggestion de @sigmavirus24 , est que cela dépend de httplib. La fonctionnalité d'urllib3 est considérablement limitée avec beaucoup de code passé à contourner les lacunes de httplib. Cependant, si la prise en charge de HTTP/2 était prise au sérieux dans cet objectif, la portée de la réimplémentation de HTTP/1.1 serait une fraction très réconfortante du travail requis.

Il y a beaucoup de PyCons, un groupe d'entre nous s'est réuni et a créé un tableau blanc pour une toute nouvelle bibliothèque http qui refactorise toutes les pièces dans l'arrangement idéal que nous pouvions imaginer à l'époque. Je serais heureux de déterrer ces notes si quelqu'un veut tenter cela.

+1 @shazow

Encore une fois, si quelqu'un a le temps et l'envie d'entreprendre ce projet assez important, j'ai esquissé une conception d'API putative qui pourrait constituer un bon point de départ.

Oui, car la seule façon pour moi d'autoriser les requêtes en tant que dépendance est si elles sont dans stdlib.

Cela dit, urllib3 contient les fonctionnalités que les gens veulent vraiment, donc l'avoir dans stdlib me suffit

Vous n'utilisez pas de dépendances ?

@dstufft c'est dans des projets qui ne le font généralement pas, où tout le monde ne peut pas se donner la peine de comprendre comment utiliser urllib. (les gens ne l'ajoutent pas en tant que dep à cause de ssl/etc en général, mais par paresse)

@dstufft également les

Bien que j'apprécie certaines personnes qui souhaitent développer des dépendances sans dépendances sur d'autres logiciels qui n'ont pas changé leur API depuis des années, ce n'est pas le lieu de la discussion.

@ sigmavirus24 Je ne suis pas d'accord. request a vu son API changer dans le passé. Les API changent, c'est pourquoi nous avons le versioning, c'est pourquoi les dépendances sont complexes. C'est un cas parfait pour cette discussion car les requêtes sont une dépendance dans de nombreux projets.

Si vous passez à la stdlib, l'API doit être stable.

@dcramer l'API s'est cassée exactement une fois, en 1.0. Les API changent, mais l'API des requêtes ne prévoit aucun changement non plus. Le seul changement que nous avons eu est l'ajout du paramètre json qui ne casse rien. Vous pouvez continuer à essayer de nous accuser de trop casser l'API, mais lorsque des projets comme OpenStack ont ​​des exigences définies comme >=1.2.3 depuis longtemps, je pense que cela en dit long sur la stabilité des requêtes. L'API a été stable, précisément parce qu'après avoir supprimé la version 1.0, nous avons rejeté tous les nouveaux ajouts à l'API (à l'exception récente évidente de l'ajout d'un paramètre json ) et nous avons été très stricts pour ne pas casser l'API. Si vous n'êtes pas un consommateur de demandes, vous ne le sauriez pas. Je ne prends donc pas personnellement votre ignorance.

De plus, si l'API stdlib est censée être si stable, expliquez pourquoi argparse a cassé son API publique entre Python 3.3 et 3.4 ?

@ sigmavirus24 vous êtes maintenant en train de transformer cela purement en un débat sur l'API. Je soulignais juste la raison pour laquelle je ne l'inclus pas parce que cela peut changer, et tout le monde l'utilise, et tout le monde utilise des versions différentes. C'est bien que vous ne changiez jamais votre API, mais je n'ai ni envie ni le temps de la suivre ou de supposer que c'est vrai.

Vous savez que Python change aussi son API, assez souvent en fait, parfois de manière très importante, peut-être avez-vous entendu parler de Python 3 ?

Bon je quitte ce débat. J'ai rendu mes opinions claires. Je ne sais pas de quoi vous râlez tous.

Je pense que certaines questions clés auxquelles répondre sont:

1. Comment voudriez-vous que la documentation standard (y compris le tutoriel) change ? Les API HTTP de la bibliothèque standard actuelle datent d'une époque où l'abstention des détails des protocoles concurrents (par exemple FTP vs HTTP) était considérée comme une approche souhaitable. Au cours de la décennie et demie qui a suivi, la communauté de développement Web a convergé sur HTTPS + JSON comme approche privilégiée pour l'interaction client/serveur de style demande/réponse pour la plupart des cas d'utilisation autres que l'exécution de commandes à distance (qui utilise SSH ou Windows RCP), et l'API de requêtes est l'implémentation client standard de facto de ce modèle pour les applications Python modernes.
2. Voulez-vous que l'API des requêtes soit mise à niveau d'une norme de facto à une norme de jure, de sorte qu'elle soit automatiquement incluse dans tous les canaux de redistribution CPython, soit soutenue par les garanties de support à long terme de CPython (et de nos redistributeurs commerciaux), ainsi que toutes les activités éducatives « bibliothèque standard uniquement » ? (Ces dernières sont encore très courantes, car les critères d'utilisation dans les environnements d'entreprise incluent souvent le support et les garanties IP, ce que CPython a, mais pas les requêtes. Dans la situation actuelle, de nombreux utilisateurs ne considéreront tout simplement pas les requêtes comme une option car c'est beaucoup trop de travail pour eux de le faire certifier pour utilisation)
3. Quels autres modules de la bibliothèque standard pourraient être améliorés en ayant des requêtes telles que l'API sur lesquelles s'appuyer ?
4. Serait-il préférable de garder les requêtes inchangées en tant qu'implémentation indépendante de la version de l'API, et d'ajouter à la place une nouvelle API inspirée des requêtes à la bibliothèque standard, semblable à la façon dont Guido a abordé le travail de normalisation ayncio ?

En ce qui concerne l'idée d'un travail de développement géré par PSF, je serais fortement contre, car nous n'avons pas l'infrastructure de gestion en place pour gérer ce genre de chose. Une proposition de subvention suggérant que le PSF contribue à un effort de financement participatif dans ce domaine serait une autre histoire (aucune garantie sans une proposition spécifique à examiner, mais c'est certainement une idée dont nous serions disposés à discuter).

Notez que certains fournisseurs peuvent déjà redistribuer les demandes, mais « fournissent-ils également un support pour les demandes ? » devient une question distincte que nous devons poser à un fournisseur ou à un fournisseur de plate-forme. Ainsi, dans un contexte de gestion des risques à long terme (pensez à des années et des décennies, plutôt qu'à des semaines ou des mois), cela signifie que nous devons soit assumer le risque et la responsabilité de l'autofinancement si l'amont s'ennuie et passe à autre chose, soit accepter une réduction potentielle du degré de choix dont nous disposons parmi les fournisseurs de plateformes.

Avec la bibliothèque standard, nous n'avons généralement pas ce souci - alors que les redistributeurs cassent parfois des choses, dans un contexte commercial, les vendeurs cassent des choses qui fonctionnent en amont vous donnent beaucoup de poids pour amener le fournisseur fautif à réparer les choses.

Oh, une autre question clé à laquelle il faut répondre avant de se porter volontaire pour maintenir des éléments dans la bibliothèque standard : êtes-vous prêt à accepter la responsabilité d'expédier un logiciel qui aide à alimenter la moitié des bourses mondiales, est l'un des langages les plus populaires pour l'infrastructure d'entreprise, un des langages les plus populaires pour la programmation scientifique (y compris utilisé pour la planification de trajectoire dans les missions spatiales interplanétaires), l'un des langages les plus populaires pour le développement Web et l'un des langages clés utilisés dans les nouvelles initiatives d'alphabétisation informatique dans les établissements d'enseignement ?

Êtes-vous également prêt à le faire alors que des personnes travaillant sur des services non critiques où des niveaux de fiabilité très faibles (souvent inférieurs à 99% de disponibilité) sont parfaitement acceptables se plaignent que vos problèmes de confiance profonds ne sont pas justifiés, et simplement une question de politique stupide et bornée qui ils ne peuvent pas se soucier d'eux-mêmes ?

Aussi, une hypothèse erronée que je voudrais corriger : la grande majorité des programmeurs Python n'auront probablement même pas entendu parler de pip, encore moins de requêtes. Ce sont les gens qui exécutent des scripts dans le système Python sur des versions Linux de support à long terme, les gens pour lesquels la plupart des développeurs open source sont prompts à exprimer un mépris indicible, sans s'arrêter pour considérer quelles circonstances pourraient être en jeu pour faire de leur approche une bonne idée.

Les temps de cycle d'adoption dans cette communauté sont intrinsèquement mesurés en années. Ce n'est qu'une infime fraction de l'industrie qui exécute actuellement une CI suffisamment rigoureuse pour pouvoir aller plus vite, et la plupart des gens dans cette fraction ne sont pas intéressés à ralentir assez longtemps pour écouter les préoccupations de ceux qui ont de grandes étendues d'existants. infrastructures que nous devons gérer et moderniser.

Cette partie post-gouffre de la courbe d'adoption de la technologie est celle que nous atteignons lorsque nous disons "oui, cette approche est maintenant suffisamment mature pour que nous puissions la pousser, ou quelque chose basé sur elle, dans la bibliothèque standard pour en faire un outil vraiment universel supposition".

Un exemple plus concret de la façon dont la bulle de filtrage de la « communauté open source » peut fausser notre point de vue : Jenkins détient plus de 70 % de part de marché dans les déploiements de CI en entreprise.

Soyez très, très prudent en vous appuyant sur des intuitions sur ce que "tout le monde sait", lorsque vous basez cette perspective sur des individus et des organisations fortement impliqués dans l'open source. La grande majorité du développement de logiciels est toujours un travail personnalisé pour répondre aux besoins d'une organisation particulière, et la grande majorité des personnes qui le font obtiennent toujours leurs outils et leurs informations auprès de fournisseurs commerciaux plutôt que de la communauté open source.

@dcramer
Je ne sais pas de quoi vous râlez tous.

Langage très approprié pour ce débat. Lorsque des contres légitimes sont faits à votre position, vous utilisez une insulte destinée à rabaisser les femmes. Par pour le cours cependant. En route,

@ncoghlan

Concernant le point 1 : Je pense que la documentation serait considérablement simplifiée avec des requêtes (requêtes similaires) dans la stdlib. L'une des premières choses que je fais lorsque j'apprends une nouvelle langue est de comprendre comment faire HTTP. Avoir cela en vedette est quelque chose dont le guide bénéficierait de toute façon.

Concernant le point 2 : Il y a une différence entre l'API et la bibliothèque étant de facto et de jure. L'API pourrait facilement être fournie par la bibliothèque standard. Je pense que votre préoccupation concernant le support serait davantage orientée vers l'inclusion des demandes (le code).

Concernant les points 3 et 4 : Je ne suis pas sûr que ce soit quelque chose à discuter ici. Peut-être que les idées de python seraient mieux.

En ce qui concerne l'idée d'un travail de développement géré par PSF, je serais fortement contre, car nous n'avons pas l'infrastructure de gestion en place pour gérer ce genre de chose.

C'est intéressant. Je ne pensais pas que c'était une probabilité, mais ce serait bien d'avoir quelque chose de mieux que http(lib).

Avec la bibliothèque standard, nous n'avons généralement pas ce souci - alors que les redistributeurs cassent parfois des choses, dans un contexte commercial, les vendeurs cassent des choses qui fonctionnent en amont vous donnent beaucoup de poids pour amener le fournisseur fautif à réparer les choses.

Je ne sais pas de quel levier tu parles. J'ai vu assurerpip, venv et d'autres choses cassées par Debian et d'autres redistributeurs dans CPython. C'est tangentiel à cette discussion cependant.

Oh, une autre question clé à laquelle il faut répondre avant de se porter volontaire pour maintenir des éléments dans la bibliothèque standard : êtes-vous prêt à accepter la responsabilité d'expédier un logiciel qui aide à alimenter la moitié des bourses mondiales, est l'un des langages les plus populaires pour l'infrastructure d'entreprise, un des langages les plus populaires pour la programmation scientifique (y compris utilisé pour la planification de trajectoire dans les missions spatiales interplanétaires), l'un des langages les plus populaires pour le développement Web et l'un des langages clés utilisés dans les nouvelles initiatives d'alphabétisation informatique dans les établissements d'enseignement ?

Comme déjà mentionné, la plupart des personnes actuellement impliquées ne poursuivraient pas le projet. Je serais probablement la seule personne, mais compte tenu de mes antécédents en matière de développement CPython en amont, il ne serait pas productif de laisser ce fardeau aux développeurs principaux existants (et futurs).

Cette partie post-gouffre de la courbe d'adoption de la technologie est celle que nous atteignons lorsque nous disons "oui, cette approche est maintenant suffisamment mature pour que nous puissions la pousser, ou quelque chose basé sur elle, dans la bibliothèque standard pour en faire un outil vraiment universel supposition".

La réalité est que ces gens ne rattraperont jamais leur retard, non ? Les gens utilisent toujours des logiciels sur Python 2.4 et 2.5. Les équilibreurs de charge de F5 ne prennent toujours en charge que Python 2.5. 2.7 sera utilisé probablement jusqu'à la fin de ma vie naturelle (qui, j'espère, sera assez longue). Sont-ce vraiment les personnes que cette décision affectera le plus fortement ? Ces mêmes personnes que vous décrivez ne feront peut-être jamais le saut vers Python 3. Et actuellement, c'est toujours un _leap_. Peut-être qu'au moment où ils auront décidé de l'envisager, Python 3.8 ou 3.9 ou 4.2 sera sorti et sera beaucoup moins compliqué pour eux.

D'accord, mon point principal est que l'objectif de l'inclusion d'une bibliothèque standard est _très_ différent de celui de la tâche plus courante consistant à fournir une bibliothèque open source à l'usage d'autres développeurs open source. Si l'équipe chargée des demandes choisit de continuer à fournir uniquement la bibliothèque gérée de manière indépendante (un service communautaire dont je suis extrêmement reconnaissant, vous faites un excellent travail !) sur des redistributeurs comme RHEL/Fedora/CentOS, Debian/Ubuntu, ActiveState, Enthought et Continuum Analytics pour récupérer le module et le standardiser _de toute façon_, de sorte que les gens puissent supposer qu'il sera toujours disponible (ou du moins assez souvent pour qu'ils soient heureux de se fier à l'API dans des scripts à fichier unique qui ne sont pas entièrement empaquetés avec les déclarations de dépendance appropriées). Cependant, la plupart des documents d'introduction orienteront probablement toujours les gens vers HTTP de la manière standard des bibliothèques. source « bibliothèque standard uniquement », ou une source qui englobe les modules tiers recommandés.

Comme pour virtualenv et PEP 405, ou Twisted+Tornado vs asyncio, ou ipaddr vs ipaddress, je ne pense pas qu'il soit logique d'inclure _requests lui-même_ dans la bibliothèque standard. Au contraire, je pense qu'il est plus logique de soutenir l'inclusion d'une API _inspirée_ de requêtes qui laisse de côté tout le code de compatibilité entre les versions, le regroupement de certificats, etc., et apporte simplement les API et la documentation par défaut pour le traitement des requêtes HTTP authentifiées jusqu'en 2015 normes. Ensuite, en 2030, nous nous plaindrons de l'archaïsme de la conception de l'API _requests_ par rapport aux normes 2030 ("HTTP? Qui l'utilise plus?!?!"), mais ce n'est pas grave, c'est comme ça que ces cycles fonctionnent (jusqu'au premier AJAX et puis JSON est arrivé, XML-RPC était le roi de la colline). Si vous obtenez 5 ans sur une conception d'API avant que les gens ne commencent à se plaindre qu'elle soit datée, vous vous en sortez plutôt bien, 10 est impressionnant et 15 est vraiment spectaculaire.

La principale chose nécessaire pour démarrer ce processus est une personne suffisamment motivée par l'idée d'avoir l'API de requêtes disponible partout pour défendre l'effort de normalisation, effectuer le travail de mise en œuvre et viser à s'engager au moins dans les premières années de maintenance stdlib. L'alternative est de continuer à s'appuyer fortement sur les redistributeurs pour atteindre les développeurs qui ne veulent pas et/ou ne peuvent pas télécharger et exécuter du code arbitraire à partir d'Internet (une catégorie qui inclut tout le monde dans n'importe quel secteur avec des exigences réglementaires strictes de diligence raisonnable, ainsi que toute personne travaillant pour d'autres organisations avec un appétit pour le risque tout aussi faible).

En ce qui concerne certains des autres points, notre effet de levier actuel avec Debian est relativement faible, tandis que l'effet de levier est meilleur avec la redistribution commercialement prise en charge où les clients payants peuvent se plaindre directement de ce qui ne fonctionne pas par rapport aux attentes que nous avons définies en tant que communauté de développement en amont.

En termes de cycles de mise à jour, l'un des éléments clés de la normalisation en amont (même en Python 3) est le consensus de la communauté. À cela, les bibliothèques qui sont des "backports" des fonctionnalités de Python 3 deviennent beaucoup plus faciles à justifier le regroupement avec Python 2. Personnellement, j'aimerais toujours voir une version sumo de Python 2 qui fait exactement ce regroupement (unittest2, subprocess32, enum34, contexlib2 , trollius, etc.), mais c'est une bataille politique à part entière, surtout en termes de persuasion des gens que l'intérêt et les ressources pour maintenir une telle distribution de sumo indépendante jusqu'en 2020 sont réellement disponibles.

@dcramer merci de nous donner de votre temps — c'est vraiment apprécié :heart:

@sigmavirus24 tout va bien :)

Je n'ai pas grand-chose à ajouter sur le front de l'inclusion stdlib, à part ça
serait bien de regarder quelques PEP ou fils de discussion ou des discussions sur ce qui devrait aller
dans le Python stdlib, et peut-être pour revenir sur l'année dernière
développement du point de vue de « comment traiter ce problème serait-il
différent s'il s'agissait d'un module de la bibliothèque standard".

Puisque cela peut devenir le fil conducteur de facto que les gens regardent quand ils disent
"que devrions-nous ajouter/modifier lorsque nous envisageons d'ajouter des demandes à la stdlib",
Je voudrais donner un autre cri pour la mise à jour de la hiérarchie des exceptions. je
ont généralement deux questions lorsqu'une demande échoue - a) Quels sont les
implications ? et b) Puis-je réessayer la demande en toute sécurité ?
Un échec de recherche DNS et un tuyau cassé ont des implications très différentes,
mais les requêtes regroupent actuellement les deux en tant que ConnectionError. j'en ai détaillé
du travail impliqué ici:
https://gist.github.com/kevinburke/b98e053a4bf9835c67bb

Heureux de discuter davantage avec les personnes intéressées.

Kevin Burke
téléphone : 925.271.7005 | vingtmillisecondes.com

Le dimanche 25 janvier 2015 à 20h15, ncoghlan [email protected] a écrit :

Comme exemple plus concret de la façon dont le filtre "communauté open source"
La bulle peut fausser notre point de vue : Jenkins détient plus de 70 % de part de marché
dans les déploiements de CI d'entreprise.

Soyez très, très prudent en vous fiant à des intuitions sur ce que « tout le monde
sait", lorsque vous basez cette perspective sur des individus et
organisations fortement impliquées dans l'open source. La grande majorité
du développement de logiciels est toujours un travail personnalisé pour répondre aux besoins d'un
organisation particulière, et la grande majorité des personnes qui le font sont
obtiennent toujours leurs outils et leurs informations auprès de fournisseurs commerciaux plutôt
que la communauté open source.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/kennethreitz/requests/issues/2424#issuecomment-71413074
.

FWIW, je pense que le libellé sur 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.

peut être mal interprété. Pour moi, cela ressemble à une attitude péjorative envers la bibliothèque standard, qui bien sûr ne se compose pas de bibliothèques mortes. J'étais irrité et je me suis abstenu d'utiliser des requêtes jusqu'à ce que j'atteigne cette page, qui est une discussion intéressante et bien meilleure que la formulation ci-dessus.