Bjoern: Python 3-Unterstützung (PEP 3333)

Kam, um dasselbe zu posten. Ich bin bereit, habe aber buchstäblich keine Erfahrung mit C-Erweiterungen. Wenn ich Ihnen helfen kann, lassen Sie es mich wissen. Wenn Sie mir ein anständiges Tool für oder ein Dokument nennen können, das die Portierung von Erweiterungen von 2 auf 3 beschreibt, werde ich darüber gießen und mein Glück versuchen.

Sollte nicht zu schwer sein, da nicht viel portiert werden muss.

Da PyString_foo in Py3 weg ist, müssen wir ein Makro für den nativen String-Typ (WSGI-Dict-Schlüssel/Werte) verwenden.

Siehe auch http://rhodesmill.org/brandon/2008/porting-ac-extension-module-to-python-30/ für allgemeine Py2-zu-Py3-Portierungshilfe.

Bei Fragen einfach eine E-Mail schreiben :)

Fürs Protokoll, hier ist der Unterschied zwischen PEP 333 und PEP 3333: http://paste.pocoo.org/show/320496/

Entschuldigung, aber alleine schaffe ich das nicht. Hoffe, hier kann jemandem etwas helfen. Ich kenne C einfach nicht.

Im aktuellen Zustand meines Forks wird der Code so kompiliert, dass vPy2 unbeeinflusst zu bleiben scheint (funktioniert) und vPy3 zumindest initialisiert werden kann. Gemäß diesem Backtrace erhalte ich bei der ersten Anfrage einen Segfault.

http://docs.python.org/py3k/howto/cporting.html beschreibt Änderungen an:

• lang/int
• Saiten
• Module

Longs/Ints

Es gibt eine Zeile mit zwei Instanzen der Notwendigkeit, von PyInt_FromLong zu PyLong_FromLong in request.c zu gehen.

Saiten

Diese Definitionen sollten alle Instanzen von PyString abdecken.

Modulinitialisierung

http://docs.python.org/py3k/c-api/module.html bietet weitere Details.

cStringIO ist veraltet

Ich glaube, die cStringIO in request.c sollten durch die Standard- PyBytes ersetzt werden.

Ich habe memcpy anstelle einer cString-Funktion verwendet und wusste einfach nicht, wie ich mit wsgi.input umgehen sollte. Ein Aufruf an PycString_IMPORT wurde gerade ersatzlos entfernt.

Modulinitialisierung: Boah ist das hässlich :-( Sie hätten wenigstens eine Routine bereitstellen können, die uns die Wahrheit verheimlicht :-(

Zeichenfolgen: Sie sollten PyUnicode für Header-Elemente in Py3 und PyString in Py2 verwenden, nicht PyBytes in Py3. Hast du das PEP 3333 Diff gelesen?

cStringIO: Gute Idee, eigentlich bin ich mir nicht sicher, warum ich cStringIO überhaupt verwende (weil die Inhaltslänge bekannt ist, also sollte ein statisches String-Objekt ausreichen). Aber cStringIO muss vor dem Aufrufen der WSGI-Anwendung in eine Datei umgewandelt werden, also verwenden wir entweder den Py3-cStringIO-Ersatz (was auch immer es ist) oder wir führen unseren eigenen Wrapper ein (das könnte ich tun).

Übrigens liegt der Segfault daran, dass das übergebene Argument ein NULL-Zeiger ist, einfach weil es keinen Anforderungstext gibt.

Modulinitialisierung: Boah ist das hässlich :-( Sie hätten wenigstens eine Routine bereitstellen können, die uns die Wahrheit verheimlicht :-(

Ja, es hilft den < 1KLOC auch nicht wirklich. Ich habe eigentlich nur einen Großteil der Boilerplate entfernt und es sieht nicht annähernd so schlimm aus.

Zeichenfolgen: Sie sollten PyUnicode für Header-Elemente in Py3 und PyString in Py2 verwenden, nicht PyBytes in Py3. Hast du das PEP 3333 Diff gelesen?

Ja, nicht ganz gut genug. Ich habe tatsächlich das offizielle Diff verwendet und mich im Gelb verlaufen, das sich fast alle auf Bytestrings bezieht. Du hast recht. Ich habe einfach den gesamten entsprechenden Code durch PyBytes und PyUnicode ersetzt und define d sie in PyString für Py2x umgewandelt. Sollen die environ und/oder die Header so gehandhabt werden ? Wenn PyUnicode_FromString auf HTTP/1.1 400 Bad Request verwendet wird, spuckt Telnet Müll aus, aber PyBytes_FromString funktioniert einwandfrei.

Google findet cStringIO und Python3 nicht, auf die zusammen mit einer kleinen Ausnahme verwiesen wird. Hier ist einer . Ich habe es einfach komplett entfernt

Das war der falsche Segfault, sorry. Ich hatte das zumindest schon bis zu seiner Quelle zurückverfolgt. Dieser beschwert sich darüber, dass wsgi_app nicht aufrufbar ist, was mich zu der Annahme veranlasst, dass ich einem lauffähigen Server nahe bin. Wenn ich das herausfinden kann, kann ich Codierungsprobleme besser lösen.

Ich denke, Sie vermasseln die native String/Unicode-String-Sache ein wenig, also hier ein paar Tipps:

Verwenden Sie zwei Header-Dateien, py2.h und py3.h , #definieren Sie alle _benutzten_ PyStr_* Routinen für den nativen Datentyp der Python-Version ( str , = PyString auf Py2 und PyUnicode auf Py3). Definieren Sie dann PyBytes_* -Makros für PyString auf Py2 (weil str von Py2 bytes von Py3 ist). PyUnicode wird bei Verwendung von Python 2 überhaupt nicht verwendet, wie PEP 3333 betont.

Die Antwort muss immer PyBytes lauten: Bei Python 2 müssen Sie keine Codierung vornehmen, da PyString Bytes sind, während ich bei Python 3 nicht sicher bin, ob die WSGI-Anwendung PyUnicode zurückgeben kann

Ihr Segfault ist sehr seltsam. Ich schätze, du hast die Refcounts woanders durcheinander gebracht ... keine Sorge, das tut jeder :)

Die aktuelle cStringIO-Ersetzung (mit memcpy ) ist defekt, da jeder Aufruf von on_body die zuvor empfangenen Daten überschreibt. Sie müssen die Gesamtmenge der memcpy Ed-Daten im Auge behalten (erweitern Sie die Struktur bjparser ). Entfernen Sie auch das body = FromString(body) (Zeile 203), da es unnötig ist und eine vollständige Textkopie erstellt.

Vielen Dank für Deine Mühe!

Hey Angelo, gibt es Neuigkeiten zur Py3-Unterstützung?

Klingeln! Gibt es Pläne, dies bald wiederzubeleben? Wenn nicht, könnte ich es vielleicht mal versuchen.

Nein, keine Pläne. Es gibt einen Port von jemand anderem https://github.com/isaiah/bjoern-py3 , aber ich habe ihn nie getestet, außerdem fügt er zu viel Code hinzu (Bytesio-Objekt).

Eine Wiederbelebung eines alten Problems, um Sie wissen zu lassen, dass bjoern immer noch der einzige WSGI-Server mit einer SO_REUSEPORT-Implementierung ist. Schade, dass wir es nicht verwenden können.

Bist du sicher? Dies ist eine Standardfunktion, die jeder Server implementieren sollte

• Kellnerin
• CherryPy
• Gunikorn
• Werkzeug
• Meinheld

Bei einigen dieser Server können Sie einen bereits geöffneten Socket passieren, aber in den meisten Fällen ist es so kompliziert, dass Sie es bereuen werden, überhaupt daran gedacht zu haben.

Um fair zu sein, uWSGI unterstützt es wahrscheinlich in irgendeiner Weise, aber die Dokumentation bringt mich um.

Ich habe dieses Projekt zu spät gefunden :-( Die ganze Zeit träume ich von einem leichtgewichtigen Python-Webserver, ohne Tänze um Nginx herum. Hast du wirklich keine Pläne mit Python3?

Nein, aber es sollte nicht zu kompliziert zu implementieren sein, also fühlen Sie sich frei, wenn Sie etwas Erfahrung mit CPython C API haben (oder bereit sind, es zu lernen)!

Warte, Bjoern unterstützt Python 3 im Jahr 2017 nicht und dieses Problem ist noch offen? Beeindruckend. Ich denke, das ist keine praktikable Option für ein Projekt :(

@jonashaag Ich habe es aufgegriffen und für python3 zum Laufen gebracht ... nicht sicher, ob dies sauber genug ist, um zusammengeführt zu werden, aber Kommentare / Vorschläge sind willkommen. :-)

https://github.com/jonashaag/bjoern/pull/104