Requests: Erwägen Sie die Aufnahme von Anfragen in die Standardbibliothek von Python 3.5

Ja, weil es den gesamten Prozess vereinfacht und die Leistung nicht beeinträchtigt. Also ja.

• Welche Auswirkungen hätte dies auf die Entwicklung und das Wachstum von Requests?
• Stimmt die Release-Häufigkeit von Requests mit der von Python überein? Ein großer Unterschied könnte hier ein guter Hinweis darauf sein, dass stdlib nicht das richtige Zuhause für Requests ist.

Lassen Sie uns einige Leute in CC setzen, deren Meinungen uns sehr wichtig sind:

@shazow @kevinburke @dstufft @alex @sigmavirus24

Was ist mit "die Standardbibliothek ist, wo die Dinge sterben" passiert?

Die Frage der Release-Kadenz ist gut; Ich wäre besorgt, die Fähigkeit der Anfrage zu verlieren, sich frei zu entwickeln. Das heißt, vielleicht wäre eine Request-Kernbibliothek gut geeignet.

Der Wert meiner 2 $CURRENCY:

Ich wäre abgeneigt, es zu tun. Ich denke, außerhalb der Standardbibliothek zu sein, hat uns die Freiheit gegeben, Entscheidungen zu treffen, die unseren Benutzern zugutekommen, ohne hinter den Richtlinien der Kernentwickler für Versionsunterstützung und -freigabe stecken zu bleiben. Es erlaubt uns, den Prioritäten der Kernentwicklung respektvoll zu widersprechen. Und es erlaubt uns, ideologische Entscheidungen zu treffen, die seit mehr als drei Jahren das Lebenselixier dieses Projekts sind.

Ich denke, die Realität sieht so aus, dass, wenn dieses Modul in die Standardbibliothek aufgenommen wird, das aktuelle Kernteam davon abweicht. Ich habe sicherlich wenig Interesse, ihm in den Sumpf zu folgen, der die Kernentwicklung darstellt. Der wahrscheinlichste Verwalter von Anfragen in der stdlib ist @sigmavirus24 , und er ist nur ein Mann. Dieser Orientierungsverlust wird im Laufe der Zeit unweigerlich zu einer Erosion der Schnittstelle der Bibliothek führen, und ich denke, das wäre eine tragische Sache.

Das einzige, was uns in der Standardbibliothek gibt, ist unsere Zeit zurück. Das ist ein guter Grund, es dort zu platzieren, wenn das Ihrer Meinung nach das ist, was es braucht, aber ich denke, wir sollten nicht so tun, als würde es die Bibliothek oder das Python-Ökosystem besser machen.

Ich glaube nicht, dass Sie der stdlib tatsächlich Anfragen _können_, ohne zuerst chardet und urllib3 hinzuzufügen oder Ihre Abhängigkeit von ihnen zu entfernen. Es gibt auch eine Sache, bei der Python kein CA-Bundle ausliefern möchte, sodass Sie es so ändern müssen, dass es das Systemplattform-Bundle verwendet, wie es Python jetzt natürlich tut.

Außerdem bin ich mir nicht sicher. Es würde es sicherlich einfacher machen, Anfragen zu erhalten, aber ein Teil meiner Arbeit an pip besteht im Wesentlichen darin, es so zu gestalten, dass es einfach ist, Dinge wie Anfragen zu erhalten, ohne sie der stdlib hinzufügen zu müssen. Darüber hinaus ist es auch etwas verwirrend, mehrere Möglichkeiten zu haben, HTTP-Anfragen in der Python-Stdlib zu stellen. Die Vereinheitlichung von urllib und urllib2 war in der Python-Stdlib eine gute Sache, und ich denke, dass das erneute Hinzufügen mit urllib.request und "requests" auch keine gute Idee ist. Schließlich glaube ich nicht, dass es vielen Leuten wirklich helfen würde, dies würde nur in 3.5+ gehen, also müsste jeder, der Anfragen verwenden möchte, entweder die Version verwenden, die sich auf PyPI befindet, oder 3.5 zu seiner minimal unterstützten Python-Version machen, was ich nicht tue Ich glaube nicht, dass dies in naher Zukunft realistisch ist.

Obwohl ich denke, dass Anfragen in der Standardbibliothek neuen Benutzern helfen würden, weiß ich nicht, ob es der Python-Community als Ganzes helfen würde. Erfahrene Benutzer wissen, wie man Requests verwendet und wie man es installiert.

Ich wäre besonders besorgt über die abschreckende Wirkung, die es auf neue Entwicklungen haben würde, da andere nicht dazu beitragen würden, da sie wissen, dass sie ihre eingebrachten Änderungen noch lange nicht in einer einfach zu verwendenden Version sehen würden.

Was ist mit dem Mittelweg, wenn Python-Distributionen standardmäßig installiert sind?

Nein, würde es nicht.

request ist für die stdlib-Aufnahme aus den vielen vor mir genannten Gründen absolut ungeeignet. Allein die Abhängigkeit von urllib3 ist ein absoluter Hingucker; wir wollen nicht, dass es in der stdlib stirbt.

Was _nützlich_ wäre, ist, etwas _Grundlegendes_ und ähnliches zu Anfragen hinzuzufügen, die auf den aktuellen http-Ressourcen von stdlib aufbauen und es Benutzern ermöglichen, einfache Get/Post-Anfragen an https zu senden, ohne Blutmagie zu praktizieren.

Auch eine freundliche Erinnerung daran, dass es nur zu Python 3 hinzugefügt wird. :) (und nicht vor Python 3.6).

Sind Sie es leid, es beizubehalten, Kenneth? ;)

Ich glaube nicht, dass wir diese Frage überhaupt diskutieren können, ohne dass jemand sagt, was aus httplib, urllib und Freunden wird. Das Hinzufügen von Anfragen, ohne die Komplexität der Auswahl zu berücksichtigen, ist meiner Meinung nach schlimmer als die Antwort "Ignoriere die stdlib, verwende einfach Anfragen". Es ist eine Regression zu den Tagen von urllib, urllib2.

Ich denke, die Realität sieht so aus, dass, wenn dieses Modul in die Standardbibliothek aufgenommen wird, das aktuelle Kernteam davon abweicht. Ich habe sicherlich wenig Interesse, ihm in den Sumpf zu folgen, der die Kernentwicklung darstellt. Der wahrscheinlichste Verwalter von Anfragen in der stdlib ist @sigmavirus24 , und er ist nur ein Mann. Dieser Orientierungsverlust wird im Laufe der Zeit unweigerlich zu einer Erosion der Schnittstelle der Bibliothek führen, und ich denke, das wäre eine tragische Sache.

Ich würde in die stdlib gehen, um zu versuchen, zu helfen, aber angesichts der Tatsache, dass genau eines von mir nicht weiß, wie viele frühere Patchsets ich eingereicht habe, akzeptiert wurde und ein anderes _reviewed_ wurde, lässt mich ich vorsichtig sein, mich mit diesem Prozess zu beschäftigen. Ich weiß, dass die Kernentwickler von wichtigeren Dingen völlig überfordert sind. Ich weiß auch, dass jemand zufällig entschieden hat, dass er httplib/http pflegen möchte, aber er ist eindeutig (noch) nicht für den Job geeignet und ich habe nicht die Geduld, an httplib zu arbeiten, wenn Patches sowohl @Lukasa als auch ich sitzen herum, ungeprüft und unbeachtet (wenn sie dringende Probleme mit der Bibliothek beheben).

Ich würde wahrscheinlich am Ende nur Anfragen verzweigen, um es weiterhin zu verwenden.

request ist für die stdlib-Aufnahme aus den vielen vor mir genannten Gründen absolut ungeeignet. Allein die Abhängigkeit von urllib3 ist ein absoluter Hingucker; wir wollen nicht, dass es in der stdlib stirbt.

Es war immer eine Behauptung von @kennethreitz (und damit des gesamten Projekts), dass urllib3 ein Implementierungsdetail ist. Viele der größten Funktionen von Anfragen werden vollständig von urllib3 gehandhabt, aber das bedeutet nicht, dass sie nicht sorgfältig in eine wirklich abhängigkeitsfreie Bibliothek reimplementiert werden könnten.

Bezüglich der Abhängigkeit vom Chardet: Es bereitet uns (und speziell mir) nur Kopfschmerzen. Früher hatte es separate Codebasen für py2 und py3, bis ich es in eine einzige Codebase-Bibliothek gebracht habe (die erst in den letzten Monaten wieder in das eigentliche Chardet zusammengeführt wurde). Die Bibliothek ist langsam und ein riesiger Speicherfresser (was viele Leute so verärgert, dass sie uns hier auf dem Issue Tracker anschreien). Es ist nicht ganz genau und Mozillas Universalchardet, dem es nachempfunden ist, wurde von Mozilla so gut wie aufgegeben. Das Entfernen von Chardet wäre also wahrscheinlich sowieso ein Nettogewinn.

Ob wir dies tun sollen oder nicht, ist mir ehrlich gesagt unbesorgt. Was auch immer in der stdlib wäre, würde am Ende nur Anfragen in der API sein. Die Einführungsrate von Python 3 ist langsam genug, dass ich nicht glaube, dass die Leute in den nächsten N Jahren davon erheblich betroffen sein werden (wobei N die weltweit unbekannte Anzahl von Jahren für 3,5 ist, die von Unternehmen in der Produktion verwendet werden).

Und wie gesagt, ich würde wahrscheinlich an diesem Punkt nur Anfragen verzweigen oder urllib3 direkt verwenden.

Ich habe das neulich mit Guido ausführlich besprochen – zuerst müsste Chardet dabei sein. Ich denke, dass urllib3 und Requests zusammen in das http-Paket aufgenommen werden könnten.

Ich bin jedoch sehr geneigt, @hynek und @dstufft zuzustimmen. Vielleicht sind Anfragen so wie sie sind in Ordnung :)

So oder so, wenn Sie eine Meinung haben, die Sie teilen möchten, können Sie diese gerne hier (oder jederzeit) teilen.

:funkelt: :Kuchen: :funkelt:

Außerdem scheint das Hinzufügen eines neuen http-Moduls zur stdlib ohne asyncio-story
blöd für mich.

Am 25. Januar 2015 um 13:15:51 Uhr Kenneth Reitz [email protected]
schrieb:

So oder so, wenn Sie eine Meinung haben, die Sie teilen möchten, sind Sie es
willkommen, es hier (oder jederzeit wirklich) zu teilen.

[Bild: :funkelt:] [Bild: :Kuchen:] [Bild: :funkelt:]

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/kennethreitz/requests/issues/2424#issuecomment -71384152
.

Ich glaube nicht, dass wir diese Frage überhaupt diskutieren können, ohne dass jemand sagt, was aus httplib, urllib und Freunden wird

Das ist mein Problem. Ich denke, der derzeitige verwirrende Zustand muss erst einmal aussortiert werden.

:+1: :Metall:

Um es klarzustellen, sollte mein obiger Kommentar zur Neuimplementierung von urllib3 für die Aufnahme in die stdlib nicht auf die leichte Schulter genommen werden. Der Arbeitsaufwand dafür wäre immens, da urllib3 das Produkt von (wahrscheinlich 10 oder mehr) Jahren Entwicklerarbeit ist.

Auch ich habe vor einigen Jahren mit Guido darüber gesprochen, urllib3 in die stdlib zu werfen, mit der Schlussfolgerung, dass dies keine gute Idee ist, aber ich bin zu diesem Zeitpunkt ziemlich neutral.

Die API von urllib3 ist seit einigen Jahren weitgehend stabil und so gut wie vollständig abwärtskompatibel. Sein Tempo ist möglicherweise noch langsamer als das der heutigen stdlib, wobei die überwiegende Mehrheit der Änderungen kleinere Korrekturen oder Sicherheitsverbesserungen sind (mit gelegentlichen abwärtskompatiblen Feature-Ergänzungen wie granularen Timeouts/Wiederholungen). Wenn jemand wirklich versuchen wollte, urllib3 in die Standardbibliothek aufzunehmen, halte ich das für keine schlechte Idee – es ist einfach nicht die _beste_ Idee.

(Ich spreche nicht für Anfragen, da es sich in einem ganz anderen Tempo mit anderen Zielen bewegt als urllib3.)

Die beste Idee wäre meiner Meinung nach, dass die PSF 1-3 Entwickler anheuert (oder vielleicht Kickstart oder so), um eine brandneue http-Bibliothek auf Asyncio mit HTTP/2-Unterstützung aufzubauen, die stark von urllib3 inspiriert ist, Anfragen , und hyper. Ich würde mich freuen, wenn so viel Code wie möglich wörtlich genommen, aber konsistent, modular und wiederverwendbar ist. Zielen Sie idealerweise auf Python 4 oder etwas anderes ab und entfernen Sie alle URL- und httplibs. Ich gehe davon aus, dass dies 6-9 Monate harter Arbeit sein würde, aber möglicherweise mehr.

Das Schlimmste an urllib3, das ich gerne ersetzt sehen würde, wenn jemand versucht, es gemäß dem Vorschlag von @sigmavirus24 umzuschreiben, ist, dass es von httplib abhängt. Die Funktionalität von urllib3 ist erheblich eingeschränkt, da viel Code aufgewendet wurde, um die Mängel von httplib zu umgehen. Wenn die HTTP/2-Unterstützung bei diesem Ziel jedoch ernst genommen würde, wäre der Umfang der Neuimplementierung von HTTP/1.1 ein sehr beruhigender Bruchteil der erforderlichen Arbeit.

Vor vielen PyCons haben sich ein paar von uns getroffen und ein Layout einer brandneuen http-Bibliothek auf einem Whiteboard erstellt, die alle Teile in die ideale Anordnung umgestaltet, die wir uns damals vorstellen konnten. Ich würde mich freuen, diese Notizen auszugraben, wenn jemand dies versucht.

+1 @shazow

Nochmals, falls jemand Zeit und Lust hat, dieses ziemlich große Projekt zu übernehmen, habe ich ein mutmaßliches API-Design skizziert, das einen guten Ausgangspunkt darstellen könnte.

Ja, denn die einzige Möglichkeit, Anfragen als Abhängigkeit zuzulassen, besteht darin, dass sie in der stdlib enthalten sind.

Das heißt, urllib3 enthält die Funktionen, die die Leute wirklich wollen, also reicht es mir, diese in stdlib zu haben

Verwenden Sie keine Abhängigkeiten?

@dstufft Dies ist in Projekten, bei Fall ist, bei denen sich nicht jeder die Mühe machen kann, herauszufinden, wie man urllib verwendet. (Die Leute fügen es nicht wegen SSL/etc im Allgemeinen als Dep hinzu, sondern aus Faulheit)

@dstufft auch Multi-Version-Deps machen es im Grunde schwierig, Dinge in Bibliotheken zu verwenden. Sie möchten wahrscheinlich Anfragen in Ihrem Projekt verwenden, und wenn wir dies benötigen, kann es zu großen Verletzungen kommen, wenn API-Änderungen in Versionen vorgenommen werden.

Obwohl ich einige Leute schätze, die Abhängigkeiten ohne Abhängigkeiten von anderer Software entwickeln möchten, deren API seit Jahren nicht geändert wurde, ist dies nicht der Ort für die Diskussion.

@sigmavirus24 Ich bin anderer Meinung. Anfragen hat in der Vergangenheit seine API geändert. APIs ändern sich, deshalb haben wir Versionsverwaltung, deshalb sind Abhängigkeiten komplex. Dies ist ein perfekter Fall für diese Diskussion, da Anfragen in vielen Projekten eine Abhängigkeit darstellen.

Wenn Sie in die stdlib wechseln, muss die API stabil sein.

@dcramer die API ist in 1.0 genau einmal kaputt json , der nichts kaputt macht. Sie können uns immer wieder vorwerfen, dass wir die API zu sehr kaputt machen, aber wenn Projekte wie OpenStack lange Zeit Anforderungen als >=1.2.3 definiert haben, sagt das meiner Meinung nach viel über die Stabilität von Anfragen aus. Die API war stabil, gerade weil wir nach der Kürzung von 1.0 alle neuen Ergänzungen der API abgelehnt haben (mit der offensichtlichen kürzlichen Ausnahme des Hinzufügens eines json Parameters) und wir sehr streng waren, die API nicht zu beschädigen. Wenn Sie kein Verbraucher von Anfragen sind, wissen Sie dies jedoch nicht. Daher nehme ich deine Unwissenheit nicht persönlich.

Wenn die stdlib-API angeblich so stabil ist, erklären Sie dann, warum argparse seine öffentliche API zwischen Python 3.3 und 3.4 kaputt gemacht hat.

@sigmavirus24 Sie verwandeln dies jetzt in eine API-Debatte. Ich habe nur darauf hingewiesen, warum ich es nicht einbeziehe, weil es sich ändern kann und jeder es verwendet und jeder andere Versionen verwendet. Es ist großartig, dass Sie nie Ihre API ändern, aber ich habe weder Lust noch Zeit, ihr zu folgen oder davon auszugehen, dass dies wahr ist.

Sie wissen, dass Python auch seine API ändert, tatsächlich ziemlich oft, manchmal auf sehr wichtige Weise, vielleicht haben Sie von Python 3 gehört?

Nun, ich verlasse diese Debatte. Ich habe meine Meinung klar gemacht. Ich bin mir nicht sicher, worüber Sie alle meckern.

Ich denke, einige der wichtigsten Fragen, die es zu beantworten gilt, sind:

1. Wie soll sich die Standarddokumentation (einschließlich des Tutorials) ändern? Die aktuellen HTTP-APIs der Standardbibliothek stammen aus einer Zeit, in der die Abstrahierung der Details konkurrierender Protokolle (z. B. FTP vs. HTTP) als wünschenswerter Ansatz angesehen wurde. In den folgenden anderthalb Jahrzehnten hat sich die Webentwicklungs-Community auf HTTPS+JSON als den bevorzugten Ansatz für die Client/Server-Interaktion im Anforderungs-/Antwortstil für die meisten Anwendungsfälle außer der Remote-Befehlsausführung (die entweder SSH oder Windows RCP verwendet) konzentriert. und die Requests-API ist die De-facto-Standard-Client-Implementierung dieses Modells für moderne Python-Anwendungen.
2. Möchten Sie, dass die Request-API von einem De-facto-Standard auf einen De-jure-Standard aktualisiert wird, so dass sie automatisch in alle CPython-Weiterverbreitungskanäle aufgenommen wird, durch die langfristigen Supportgarantien von CPython (und unseren kommerziellen Weiterverteilern) unterstützt wird, sowie alle Bildungsaktivitäten "nur Standardbibliothek"? (Letztere sind immer noch sehr verbreitet, da die Kriterien für den Einsatz in Unternehmensumgebungen oft Support und IP-Garantien beinhalten, die CPython hat, Anfragen jedoch nicht. In der aktuellen Situation werden viele Benutzer Anfragen einfach nicht als Option in Betracht ziehen, weil es ist viel zu viel Arbeit für sie, es für die Verwendung akkreditieren zu lassen)
3. Welche anderen Module in der Standardbibliothek könnten durch Anfragen wie API verbessert werden, auf denen aufgebaut werden kann?
4. Wäre es besser, die Anfragen selbst als versionsunabhängige Implementierung der API unverändert zu lassen und stattdessen eine neue, von Anfragen inspirierte API zur Standardbibliothek hinzuzufügen, ähnlich wie Guido an die Standardisierungsarbeit von ayncio herangegangen ist?

Was die Idee von PSF-verwalteter Entwicklungsarbeit angeht, wäre ich stark dagegen, da wir nicht über die Management-Infrastruktur verfügen, um solche Dinge zu bewältigen. Ein Zuschussantrag, der vorschlägt, dass die PSF zu einem Crowdfunding-Projekt in diesem Bereich beiträgt, wäre eine andere Geschichte (keine Garantien ohne einen spezifischen Vorschlag zur Überprüfung, aber es ist sicherlich eine Idee, über die wir gerne diskutieren würden).

Beachten Sie, dass einige Anbieter möglicherweise bereits Anfragen weiterverteilen, aber "bieten sie auch Unterstützung für Anfragen?" wird zu einer separaten Frage, die wir einem Anbieter oder Plattformanbieter stellen müssen. In einem langfristigen Risikomanagement-Kontext (denken Sie an Jahre und Jahrzehnte statt Wochen oder Monate) bedeutet dies, dass wir entweder das Risiko und die Verantwortung der Selbsthilfe übernehmen müssen, wenn der Upstream sich langweilt und zu etwas anderem übergeht, oder sonst akzeptieren eine potenzielle Verringerung der Auswahl, die wir bei Plattformanbietern haben.

Mit der Standardbibliothek haben wir diese Bedenken im Allgemeinen nicht - während Weiterverteiler gelegentlich Dinge kaputt machen, bieten Ihnen Anbieter, die Sachen kaputt machen, die vorgelagert funktionieren, in einem kommerziellen Kontext ziemlich viel Einfluss, um den beleidigenden Anbieter dazu zu bringen, Dinge zu reparieren.

Oh, eine weitere wichtige Frage, die Sie beantworten sollten, bevor Sie sich freiwillig zur Pflege der Standardbibliotheken melden: Sind Sie bereit, die Verantwortung für den Versand von Software zu übernehmen, die dazu beiträgt, die Hälfte der Börsen der Welt mit Strom zu versorgen, ist eine der beliebtesten Sprachen für die Unternehmensinfrastruktur, eine einer der beliebtesten Sprachen für die wissenschaftliche Programmierung (einschließlich der Verwendung für die Flugbahnplanung bei interplanetaren Weltraummissionen), eine der beliebtesten Sprachen für die Webentwicklung und eine der Schlüsselsprachen, die in neuen Initiativen zur Computerkompetenz in Bildungseinrichtungen eingesetzt werden?

Sind Sie auch bereit, dies zu tun, während sich Mitarbeiter, die an nicht kritischen Diensten arbeiten, bei denen sehr niedrige Zuverlässigkeitsniveaus (oft weniger als 99 % Betriebszeit) durchaus akzeptabel sind, darüber beschweren, dass Ihre tiefgreifenden Vertrauensprobleme ungerechtfertigt sind und lediglich eine dumme, versteckte Politik sind, die? sie können sich nicht darum kümmern?

Auch eine falsche Annahme, die ich korrigieren möchte: Die überwiegende Mehrheit der Python-Programmierer hat wahrscheinlich noch nicht einmal von pip gehört, geschweige denn von Anfragen. Dies sind die Leute, die Skripte im System Python auf Linux-Versionen mit langfristiger Unterstützung ausführen, für die die meisten Open-Source-Entwickler schnell eine unsägliche Verachtung zum Ausdruck bringen, ohne darüber nachzudenken, welche Umstände im Spiel sein könnten, um ihren Ansatz zu einer guten Idee zu machen.

Die Annahmezykluszeiten in dieser Community werden von Natur aus in Jahren gemessen. Es ist nur ein verschwindend kleiner Teil der Branche, der derzeit eine ausreichend rigorose CI anwendet, um schneller voranzukommen, und die meisten Leute in dieser Fraktion sind nicht daran interessiert, lange genug langsamer zu werden, um sich die Bedenken derjenigen anzuhören, die große Teile der Existenz haben Infrastruktur, die wir verwalten und modernisieren müssen.

Diesen Post-Chasm-Teil der Technologie-Einführungskurve erreichen wir, wenn wir sagen: "Ja, dieser Ansatz ist jetzt so ausgereift, dass wir ihn oder etwas darauf basierendes in die Standardbibliothek aufnehmen können, um es zu einer wirklich universellen" zu machen Annahme".

Ein konkreteres Beispiel dafür, wie die Filterblase der „Open Source Community“ unsere Perspektive verzerren kann: Jenkins hält mehr als 70 % Marktanteil bei CI-Implementierungen in Unternehmen.

Seien Sie sehr, sehr vorsichtig, wenn Sie sich auf Intuitionen über das verlassen, was "jeder weiß", wenn Sie diese Perspektive auf Einzelpersonen und Organisationen stützen, die sich stark mit Open Source beschäftigen. Die überwiegende Mehrheit der Softwareentwicklung ist immer noch Maßarbeit, um die Anforderungen einer bestimmten Organisation zu erfüllen, und die überwiegende Mehrheit der Leute, die dies tun, bezieht ihre Tools und Informationen immer noch von kommerziellen Anbietern und nicht von der Open-Source-Community.

@dcramer
Ich bin mir nicht sicher, worüber Sie alle meckern.

Sehr geeignete Sprache für diese Debatte. Wenn Ihre Position legitimiert wird, verwenden Sie eine Verleumdung, die Frauen erniedrigen soll. Par für den Kurs aber. Weiter so,

@ncoghlan

Zu Punkt 1: Ich denke, die Dokumentation würde mit Requests (request-alike) in der stdlib drastisch vereinfacht. Eines der ersten Dinge, die ich mache, wenn ich eine neue Sprache lerne, ist herauszufinden, wie HTTP funktioniert. Dies zu haben, ist etwas, von dem der Guide unabhängig davon profitieren würde.

Zu Punkt 2: De facto und de jure gibt es einen Unterschied zwischen der API und der Bibliothek. Die API könnte problemlos von der Standardbibliothek bereitgestellt werden. Ich denke, Ihr Anliegen bezüglich des Supports wäre eher darauf ausgerichtet, dass Anfragen (der Code) aufgenommen werden.

Zu Punkt 3 & 4: Ich bin mir nicht sicher, ob das hier diskutiert werden soll. Vielleicht wären Python-Ideen besser.

Was die Idee von PSF-verwalteter Entwicklungsarbeit angeht, wäre ich stark dagegen, da wir nicht über die Management-Infrastruktur verfügen, um solche Dinge zu bewältigen.

Das ist interessant. Ich hielt es nicht für eine Wahrscheinlichkeit, aber es wäre großartig, etwas Besseres als http(lib) zu haben.

Mit der Standardbibliothek haben wir diese Bedenken im Allgemeinen nicht - während Weiterverteiler gelegentlich Dinge kaputt machen, bieten Ihnen Anbieter, die Sachen kaputt machen, die vorgelagert funktionieren, in einem kommerziellen Kontext ziemlich viel Einfluss, um den beleidigenden Anbieter dazu zu bringen, Dinge zu reparieren.

Ich bin mir nicht sicher, von welcher Hebelwirkung du redest. Ich habe gesehen, dass Certainpip, venv und andere Dinge von Debian und anderen Weiterverteilern in CPython beschädigt wurden. Das ist jedoch tangential zu dieser Diskussion.

Oh, eine weitere wichtige Frage, die Sie beantworten sollten, bevor Sie sich freiwillig zur Pflege der Standardbibliotheken melden: Sind Sie bereit, die Verantwortung für den Versand von Software zu übernehmen, die dazu beiträgt, die Hälfte der Börsen der Welt mit Strom zu versorgen, ist eine der beliebtesten Sprachen für die Unternehmensinfrastruktur, eine einer der beliebtesten Sprachen für die wissenschaftliche Programmierung (einschließlich der Verwendung für die Flugbahnplanung bei interplanetaren Weltraummissionen), eine der beliebtesten Sprachen für die Webentwicklung und eine der Schlüsselsprachen, die in neuen Initiativen zur Computerkompetenz in Bildungseinrichtungen eingesetzt werden?

Wie bereits erwähnt, würden die meisten der derzeit Beteiligten das Projekt nicht fortsetzen. Ich wäre wahrscheinlich die einzige Person, aber angesichts meiner Erfolgsbilanz bei der Upstream-CPython-Entwicklung wäre es nicht produktiv, diese Last den bestehenden (und anderen zukünftigen) Core-Entwicklern zu überlassen.

Diesen Post-Chasm-Teil der Technologie-Einführungskurve erreichen wir, wenn wir sagen: "Ja, dieser Ansatz ist jetzt so ausgereift, dass wir ihn oder etwas darauf basierendes in die Standardbibliothek aufnehmen können, um es zu einer wirklich universellen" zu machen Annahme".

Die Realität ist jedoch, dass diese Leute nie aufholen werden, oder? Die Leute führen immer noch Software auf Python 2.4 und 2.5 aus. Die Load Balancer von F5 unterstützen weiterhin nur Python 2.5. 2.7 wird wahrscheinlich bis zum Ende meines natürlichen Lebens (das hoffentlich noch lange dauern wird) im Einsatz sein. Sind das wirklich die Menschen, die von dieser Entscheidung am stärksten betroffen sind? Dieselben Leute, die Sie beschreiben, werden vielleicht nie den Sprung zu Python 3 schaffen. Und derzeit ist es immer noch ein _Sprung_. Vielleicht wird Python 3.8 oder 3.9 oder 4.2 zu dem Zeitpunkt sein, an dem sie sich entschieden haben, es in Betracht zu ziehen, und es wird für sie viel weniger lästig sein.

Richtig, mein Hauptpunkt ist, dass sich das Ziel der Einbindung von Standardbibliotheken _sehr_ von der üblicheren Aufgabe unterscheidet, eine Open-Source-Bibliothek zur Verwendung durch andere Open-Source-Entwickler bereitzustellen. Wenn sich das Anfrageteam dafür entscheidet, weiterhin nur die unabhängig verwaltete Bibliothek bereitzustellen (ein Community-Service, für den ich sehr dankbar bin, ihr leistet großartige Arbeit!) und keinen Vorstoß zur Standardisierung der API unterstützt, dann verlassen wir uns darauf auf Redistributoren wie RHEL/Fedora/CentOS, Debian/Ubuntu, ActiveState, Enthought und Continuum Analytics, um das Modul aufzunehmen und _jedenfalls_ darauf zu standardisieren, so dass die Leute davon ausgehen können, dass es immer verfügbar sein wird (oder zumindest oft genug für sie). glücklich, sich auf die API in Einzeldateiskripten zu verlassen, die nicht vollständig mit entsprechenden Abhängigkeitsdeklarationen gepackt sind). Die meisten einführenden Dokumentationen werden die Leute jedoch wahrscheinlich immer noch dazu bringen, HTTP auf die Standardbibliotheksmethode zu verwenden. Ob die Leute also "HTTP für Python, Ausgabe 2001" oder "HTTP für Python, Ausgabe 2015" lernen, hängt davon ab, ob sie es von einer "Nur Standardbibliothek"-Quelle oder eine, die empfohlene Module von Drittanbietern umfasst.

Wie bei virtualenv und PEP 405 oder Twisted+Tornado vs. asyncio oder ipaddr vs. ipaddress, halte ich es jedoch nicht für sinnvoll, _requests selbst_ in die Standardbibliothek aufzunehmen. Ich denke eher, dass es sinnvoller ist, die Aufnahme einer _inspirierten_ API für Anfragen zu unterstützen, die den gesamten Cross-Versions-Kompatibilitätscode, die Zertifikatsbündelung usw Standards. 2030 werden wir uns dann darüber beschweren, wie archaisch das _requests_-API-Design nach 2030-Standards ist ("HTTP? Wer nutzt das noch?!?!"), aber das ist in Ordnung, so funktionieren diese Zyklen (bis zum ersten AJAX und dann kam JSON, XML-RPC war King of the Hill). Wenn Sie 5 Jahre aus einem API-Design herausholen, bevor sich die Leute darüber beschweren, dass es veraltet ist, machen Sie es ziemlich gut, 10 sind beeindruckend und 15 sind wirklich spektakulär.

Das Wichtigste, um diesen Prozess zu starten, ist jemand, der ausreichend motiviert ist von der Idee, die Request-API überall verfügbar zu haben, um die Standardisierungsbemühungen zu unterstützen, die Implementierungsarbeit zu leisten und sich zumindest für die ersten Jahre der stdlib-Wartung zu verpflichten. Die Alternative besteht darin, sich weiterhin stark auf Weiterverteiler zu verlassen, um Entwickler zu erreichen, die nicht willens und/oder in der Lage sind, beliebigen Code aus dem Internet herunterzuladen und auszuführen (eine Kategorie, die jeden in jeder Branche mit strengen regulatorischen Sorgfaltspflichten umfasst, sowie jeden Arbeit für andere Organisationen mit ähnlich geringer Risikobereitschaft).

In Bezug auf einige der anderen Punkte ist die derzeitige Hebelwirkung bei Debian relativ schwach, während die Hebelwirkung bei der kommerziell unterstützten Umverteilung besser ist, bei der zahlende Kunden sich direkt über Dinge beschweren können, die im Verhältnis zu den von uns als Upstream-Entwicklungsgemeinschaft gesetzten Erwartungen gebrochen wurden.

In Bezug auf Update-Zyklen ist eines der wichtigsten Dinge, die die Upstream-Standardisierung (sogar in Python 3) vermittelt, der Konsens der Community. Außerdem wird es für Bibliotheken, die "Backports" von Python 3-Funktionen sind, viel einfacher, die Bündelung mit Python 2 zu rechtfertigen. Ich persönlich würde immer noch gerne eine Sumo-Version von Python 2 sehen, die genau diese Bündelung macht (unittest2, subprocess32, enum34, contexlib2 , Trollius usw.), aber das ist ein ganz separater politischer Kampf für sich, insbesondere wenn es darum geht, die Leute davon zu überzeugen, dass das Interesse und die Ressourcen, um eine solche Weiterverteiler-unabhängige Sumo-Verteilung bis 2020 aufrechtzuerhalten, tatsächlich verfügbar sind.

@dcramer, danke, dass du uns deine Zeit

@sigmavirus24 alles gut :)

Ich habe an der stdlib-Inklusionsfront nicht viel hinzuzufügen, außer es
Es wäre nett, sich ein paar PEPs oder Threads oder Gespräche darüber anzuschauen, was gehen sollte
in der Python-Stdlib, und vielleicht um auf das letzte Jahr oder so zurückzublicken
Entwicklung aus der Perspektive, "wie wäre der Umgang mit diesem Thema"
anders, wenn es sich um ein Modul in der Standardbibliothek handelt".

Da dies der De-facto-Thread werden könnte, auf den die Leute schauen, wenn sie sagen
"Was sollten wir hinzufügen/ändern, wenn wir erwägen, Anfragen zur stdlib hinzuzufügen",
Ich möchte noch einen Schrei für die Aktualisierung der Ausnahmehierarchie aussprechen. ich
haben normalerweise zwei Fragen, wenn eine Anfrage fehlschlägt - a) Was sind die
Auswirkungen? und b) Kann ich die Anfrage sicher wiederholen?
Ein DNS-Lookup-Fehler und eine defekte Pipe haben sehr unterschiedliche Auswirkungen.
aber Anfragen gruppieren derzeit beide als ConnectionError. Ich habe einige detailliert beschrieben
der hier anfallenden Arbeiten:
https://gist.github.com/kevinburke/b98e053a4bf9835c67bb

Gerne mehr mit Interessierten diskutieren.

Kevin Burke
Telefon: 925.271.7005 | zwanzigmillisekunden.com

Am Sonntag, den 25. Januar 2015 um 20:15 Uhr schrieb ncoghlan [email protected] :

Als konkreteres Beispiel dafür, wie die "Open-Source-Community" filtert
Blase kann unsere Perspektive verzerren: Jenkins hält mehr als 70 % Marktanteil
in Unternehmens-CI-Bereitstellungen.

Seien Sie sehr, sehr vorsichtig, wenn Sie sich auf Intuitionen verlassen, was "jeder"
weiß", wenn Sie diese Perspektive auf Einzelpersonen stützen und
Organisationen, die sich stark mit Open Source beschäftigen. Die überwiegende Mehrheit
der Softwareentwicklung ist immer noch Maßarbeit für die Bedürfnisse eines
eine bestimmte Organisation, und die überwiegende Mehrheit der Leute, die das tun, sind
ihre Tools und Informationen immer noch von kommerziellen Anbietern beziehen
als die Open-Source-Community.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/kennethreitz/requests/issues/2424#issuecomment -71413074
.

FWIW, ich denke der Wortlaut auf 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.

kann falsch interpretiert werden. Für mich klingt das nach einer abwertenden Haltung gegenüber der Standardbibliothek, die natürlich nicht aus toten Bibliotheken besteht. Ich war irritiert und unterließ es, Anfragen zu verwenden, bis ich auf diese Seite stieß, die eine interessante Diskussion ist und viel besser ist als der obige Wortlaut.