Requests: Warum standardmäßig auf simplejson?

Danke für diesen Bericht! Bitte lesen Sie Ausgabe Nr. 2516 für das letzte Mal, als dies diskutiert wurde.

Um es klar zu sagen, ich bin jetzt wie damals offen dafür, simplejson als Option vollständig zu entfernen, aber @kennethreitz wollte es dort. =)

Ich sage nicht, dass es entfernt werden sollte ... aber vielleicht gibt es eine bessere Möglichkeit, den Import zu steuern. Es ist möglich, dass Bibliotheken miteinander in Konflikt geraten. Könnte es eine Möglichkeit geben, die JSON-Bibliothek für Anfragen anzugeben?

In der Vergangenheit hatte ich den Eindruck, dass ein frisch kompiliertes simplejson bessere Leistungsmerkmale aufweist als das in Python 2.6 integrierte Modul json .

Ich glaube, die "Beschleunigungen" wurden im json -Modul erst mit 2.7 aktiviert.

Erinnere mich hier aus der Erinnerung, also kann es sein, dass ich nicht richtig bin.

Das Steuern von Importen ist _extrem_ angespannt, weil es darauf angewiesen ist, den Import bis zu einem späteren Zeitpunkt in der Ausführung zu verzögern. Ich bin ziemlich abgeneigt, das zu tun, weil es dazu führt, dass Fehler an seltsamen Stellen auftauchen und das Leben im Allgemeinen seltsam schwierig machen kann. Wenn wir es behalten wollen, sollten wir es behalten, wenn wir es entfernen wollen, sollten wir es entfernen.

Die letzten drei Kommentare hier geben unsere Haltung gut wieder https://github.com/kennethreitz/requests/pull/2516#issuecomment -89005463

Was würden Sie also vorschlagen, wenn zwei Bibliotheken miteinander in Konflikt geraten? Monkey patcht die Anforderungsbibliothek, um zu steuern, welcher JSON-Import verwendet wird?

Streit miteinander? Ich verstehe nicht. Wenn simplejson auf Ihrem System nicht richtig funktioniert, finden Sie wahrscheinlich den Grund dafür heraus oder deinstallieren es.

Ich bin nicht gegen das Entfernen, wenn es für einige Benutzer wirklich ein Problem darstellt, da ich nicht glaube, dass es irgendjemanden in messbarer Weise beeinträchtigen würde, aber es ist derzeit einer dieser netten letzten Schliffe, die die Verwendung von Requests zu einem Vergnügen machen – ein extremes Maß an Nachdenklichkeit.

Vor fünf Jahren kümmerten sich die Leute viel mehr um die Geschwindigkeit ihrer Kodierungs-/Dekodierungs-Serialisierungsbibliotheken, als es heute den Anschein hat. Dies war die beste Vorgehensweise. Ich denke auch nicht, dass es schädlich ist.

Es sollte auch beachtet werden, dass 2.6 heute viel weniger verwendet wird als noch vor fünf Jahren.

@digitaldavenyc Die einzig akzeptable Möglichkeit, diesen Importfluss zu steuern, wäre die Unterstützung einer Umgebungsvariable, z. B. REQUESTS_NO_SIMPLEJSON . Das wird nicht passieren.

Ja, ich gebe mein Szenario aus der realen Welt ... Eine Bibliothek verwendet Anfragen und stellte nach einigem Graben fest, dass sie die JSON-Decodierung aus verschiedenen Gründen überschrieb. Es funktioniert hervorragend mit Anfragen, wenn die Standard-Python-JSON-Bibliothek verwendet wird, aber eine andere Python-Bibliothek entschied sich für den Import von Simplejson und brach die Dekodierung in Anfragen. Man könnte sagen, dass das Überschreiben ein echtes Problem war, aber ich denke, der Mangel an Kontrolle darüber, welche JSON-Bibliotheksanforderungen verwendet werden, ist ein Problem.

Es sollte auch beachtet werden, dass unsere json-Unterstützung sehr einfach ist und in keiner Weise für die Verwendung der Bibliothek erforderlich ist – Sie können einfach json.loads(response.content) (obwohl wir ein bisschen mehr mit Codierungen machen, glaube ich).

Hat simplejson in neueren Versionen von Python 3.3+ tatsächlich Leistungssteigerungen gegenüber nativem json?

Keine Ahnung, ich bezweifle es. Ich sagte ausdrücklich Python 2.6.

Oder json.loads(response.text) . Ja, es ist schön, eine Convenience-Methode zu verwenden, aber Requests hat viele Convenience-Methoden, die in bestimmten Fällen umgangen werden, und dies ist ein großartiges Beispiel für einen Fall (in dem Sie eine andere Anforderung an simplejson haben, die genau identisch mit dem json-Modul der Standardbibliothek funktionieren sollte ).

Fragen zur Leistung von simplejson sind für Anfragen jedoch nicht relevant.

Ich wollte gerade sagen, dass es vielleicht keinen Grund gibt, etwas in Anfragen zu ändern, aber wenn es keine leistungsbezogenen Gründe für die Verwendung von simplejson gibt, warum sollte man es dann noch in Anfragen aufnehmen?

Hast du irgendwelche Kommentare gelesen, die ich vorher gemacht habe?

Leistungsbezogene Gründe == Python 2.6.x.

@kennethreitz Genau. Sie haben gerade erwähnt, dass nicht mehr viele Leute Python 2.6 verwenden. Ist es immer noch ein nettes Feature, das es wert ist, aufgenommen zu werden?

Vielleicht, vielleicht nicht. Das ist, was meine obigen Aussagen postulierten.

Insbesondere https://github.com/kennethreitz/requests/issues/3052#issuecomment -197025994

Ich stimme Ihnen zu, dass das Einbeziehen von Simple-JSON-Unterstützung vor 3-4 Jahren großartig war, es zeigte dieses Maß an Nachdenklichkeit, das Anfragen zu einer großartigen Bibliothek macht. Aber ich sehe keinen Wert darin, simple-json in zukünftige Versionen einzubeziehen. Wenn nur Anwendungen, die Python 2.6 verwenden, Vorteile aus der Verwendung von simple-json ziehen können, erscheint es sinnlos, es länger einzubeziehen, da dies die niedrigste Version von Python ist, die derzeit von Anfragen unterstützt wird.

Ich bin nur ein Benutzer von Anfragen, aber ihr verwaltet die Bibliothek und die Entscheidung liegt bei euch.

Ich stimme zu. Ein paar Möglichkeiten hier:

1. Dinge so lassen, wie sie sind (immer bevorzugt)
2. Simplejson-Logik vollständig entfernen (ich denke, das wäre in Ordnung)
3. Beschränken der simplejson-Logik auf nur 2.6 (unideal, würde aber mögliche Nebenwirkungen begrenzen)

Ich mag 1 am besten, mit einem "wenn es nicht kaputt ist, repariere es nicht!" Mentalität, sehr locker gehalten. Ich weiß, dass @sigmavirus24 und @Lukasa 2 bevorzugen, und wenn es den (minimalen) Aufwand wert ist, bin ich nicht dagegen, wenn sie dafür sind.

Ich würde denken, dass 3 wahrscheinlich die beste Option wäre, da Benutzer von Python 2.6 möglicherweise immer noch simple-json verwenden und es ab sofort immer noch von Anfragen unterstützt wird. Könnte es eventuell Probleme damit geben?

Ich glaube nicht, dass es irgendjemand bemerken oder sich darum kümmern wird. Ich habe es _für_ sie reingelegt, weil _ich_ mich mehr darum gekümmert habe als sie :)

Wenn sich die Community wirklich um Geschwindigkeit kümmern würde, würden wir alle die ganze Zeit ujson verwenden. Heutzutage geht es vor allem um Bequemlichkeit und darum, sich an die Masse zu halten.

Im Internet gefunden:

Mit simplejson (bei Verwendung des Speedups-Moduls) hängt der Typ von Zeichenfolge von seinem Wert ab, dh es dekodiert Zeichenfolgen als Typ „str“, wenn ihre Zeichen nur ASCII sind, ansonsten jedoch als „Unicode“. Seltsamerweise decodiert es Zeichenfolgen immer als Unicode (wie das Standard-json-Modul), wenn Beschleunigungen deaktiviert sind.

Anfängerfehler, obwohl vor Python3 durchaus üblich. Anfragen taten dies jahrelang für Response.content , bevor ich anfing, an der Unterstützung von Python 3 zu arbeiten, und gezwungen war, die eindeutige Eigenschaft Response.text für Unicode zu erstellen (viel besseres Design).

Ich vermute, dass dies das Problem ist, auf das Sie stoßen.

Angesichts dieser Informationen wird es 2 sein: Simplejson-Logik vollständig entfernen.

2 ist wahrscheinlich langfristig der beste Weg.

Nun, ich habe es geschätzt, als Sie simple-json damals im Jahr 2010 aufgenommen haben, falls das ein Trost ist :-)

Wäre es am sinnvollsten, die ursprüngliche PR https://github.com/kennethreitz/requests/pull/2516 erneut zu öffnen?

Nr. #2516 bizarr hinzugefügter Code, um auf simplejson zurückzugreifen, das möglicherweise niemals getroffen werden könnte (alle Python-Versionen haben ein json -Modul, das erfolgreich importiert wird.

Richtig, das ergibt keinen Sinn. Neue PR also?

Jep. =)

Mit #3056 zusammengeführt schließe ich dies.

Ich stimme zu. Ein paar Möglichkeiten hier:

1. Dinge so lassen, wie sie sind (immer bevorzugt)
2. Simplejson-Logik vollständig entfernen (ich denke, das wäre in Ordnung)
3. Beschränken der simplejson-Logik auf nur 2.6 (unideal, würde aber mögliche Nebenwirkungen begrenzen)

Ich mag 1 am besten, mit einem "wenn es nicht kaputt ist, repariere es nicht!" Mentalität, sehr locker gehalten. Ich weiß, dass @sigmavirus24 und @Lukasa 2 bevorzugen, und wenn es den (minimalen) Aufwand wert ist, bin ich nicht dagegen, wenn sie dafür sind.

2 ist wahrscheinlich langfristig der beste Weg.

Ich habe auch das gleiche Problem, aber ich kann den Simplejson nicht mit " pip3 uninstall simplejson " entfernen. Wenn dies nicht der Weg ist, ihn zu entfernen, sagen Sie mir bitte, wie ich ihn entfernen kann

simplejson ist das gleiche Modul wie 'json', nur aktueller (und potenziell schneller)

von meinem Iphone gesendet

Am 15. November 2019 um 13:45 Uhr schrieb Bhanu Prakash [email protected] :

,
Ich stimme zu. Ein paar Möglichkeiten hier:

Dinge so lassen, wie sie sind (immer bevorzugt)
Simplejson-Logik vollständig entfernen (ich denke, das wäre in Ordnung)
Beschränken der simplejson-Logik auf nur 2.6 (unideal, würde aber mögliche Nebenwirkungen begrenzen)
Ich mag 1 am besten, mit einem "wenn es nicht kaputt ist, repariere es nicht!" Mentalität, sehr locker gehalten. Ich weiß, dass @sigmavirus24 und @Lukasa 2 bevorzugen, und wenn es den (minimalen) Aufwand wert ist, bin ich nicht dagegen, wenn sie dafür sind.

2 ist wahrscheinlich langfristig der beste Weg.

Ich habe auch das gleiche Problem, aber ich kann den Simplejson nicht mit " pip3 uninstall simplejson " entfernen. Wenn dies nicht der Weg ist, ihn zu entfernen, sagen Sie mir bitte, wie ich ihn entfernen kann

—
Sie erhalten dies, weil Sie den Öffnungs-/Schließstatus geändert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder kündigen Sie sie.

Daher wird es zuerst verwendet, wenn es verfügbar ist, da es für den Benutzer wahrscheinlich schneller ist, wenn er das Rad verwendet oder die c-Erweiterungen verfügbar hat. Die Deserialisierung ist rechnerisch ein sehr langsamer Vorgang, insbesondere wenn Sie Hunderttausende von Anforderungen ausführen. alles, was wir tun können, um dies zu optimieren, sollten wir tun.

Das Entfernen wäre nicht API-inkompatibel, aber es würde eine neue Version von Anforderungen erfordern, die nur Sicherheitsfixes enthalten sollten. Benutzer verlassen sich möglicherweise auf diese Funktionalität, und sie fügt der Codebasis keinen Schaden zu.