Die Misere mit Python 3 und WSGI

[sma]

Graham Dumpleton (bei dem Namen muss ich irgendwie an Harry Potter denken) ist der Autor von mod_wsgi und unzufrieden mit der aktuellen Situation bzw. des WSGI-Standards und Python 3.x.

Daher hat er einen wirklich langen Blog-Artikel geschrieben, in dem er seinen Vorschlag für die Situation darlegt und gegen andere Vorschläge abwägt: http://blog.dscpl.com.au/2009/09/roadma ... ation.html

Lesenswert, aber ich muss gestehen, ich habe resigniert. Ich werde mir noch Tornado als Python 2.x basiertes asynchrones und von WSGI unabhängiges Rahmenwerk anschauen, ansonsten aber eher Richtung Ruby und JavaScript schauen.

Stefan

[Defnull]

Als Jemand, der mitten drin steckt (Autor eines WSGI Frameworks) kann ich die Sache nur bestätigen. WSGI ist kaputt. Es war nie richtig heile und mit Python 3 ist es endgültig hinüber.

Die Vorschläge in dem Blog-Post ergeben alle Sinn und klingen gut überlegt, aber ich würde gerne eine noch radikalere Änderung sehen. Weg vom alten CGI Ballast und weg von der Python 2 Kompatibilität. Ich hätte gerne etwas komplett und perfekt auf Python 3 zu geschnittenes ohne Kompromisse. Für Python2 funktioniert das alte WSGI gut genug.

[Hyperion]

Ich fände es ja gut, wenn Mitsuhiko sich dazu mal äußern würde. In seinem Blog deutet er ja bereits an, dass er sich zu Grahams Kritik äußern will (ist damit der oben verlinkte Blogeintrag gemeint?)

Ian and I started working on an updated version of PEP 333 but we immediately got some negative feedback from Graham (who unfortunately wasn't there) on some of the changes. I will update the PEP next week to clarify the points he brought up and read up on the web-sig to not miss anything.

Tja, da müssen wir uns leider noch ein wenig gedulden

[DasIch]

Die Vorschläge in dem Blog-Post ergeben alle Sinn und klingen gut überlegt, aber ich würde gerne eine noch radikalere Änderung sehen. Weg vom alten CGI Ballast und weg von der Python 2 Kompatibilität. Ich hätte gerne etwas komplett und perfekt auf Python 3 zu geschnittenes ohne Kompromisse. Für Python2 funktioniert das alte WSGI gut genug.

Dann sollte man ein neues Protokoll entwickeln aber wichtig ist das WSGI prinzipiell erstmal läuft.

[sma]

Habe gerade mal einen Blick auf die "Spezifikationen" von JSGI und Rack geworfen und muss sagen: Amateure. In beiden Fällen wird kein Wort über Encodings und Bytes vs. Zeichen gesagt. Das ist alles genau der gleiche Mist.

Laut HTTP 2616 besteht z.B. der Header eines Requests aus TEXT, was OCTETs außer CTL aber mit LWS sind, wobei CTL für OCTET 0-31 und 127 steht, LWS für CR (13) LF (10) gefolgt von SP (32) oder HT (9). Es soll ISO-8859-1 angenommen werden, AUSSER, wenn gemäß RFC 2047 quoted printables benutzt werden, also z.B. `=?ISO-8859-15?Q?=A4?=`, wenn jemand darauf besteht, ein Euro-Zeichen in eine Header einzubauen. Los, welches Rahmenwerk kann das?!

Ich habe auch schon gesehen, dass Leute versuchen, UTF-8 im Header zu benutzen, was aber AFAIK schief gehen muss, weil da OCTETS in CTL-Bereich fallen können, was streng genommen nicht erlaubt ist.

Stefan

[jens]

Was ist mit uWSGI: http://projects.unbit.it/uwsgi/ wird dort darüber nachgedacht?

[Leonidas]

Naja, der implementiert doch auch nur WSGI und eben mit allen Mängeln die WSGI nun mal hat.

[Darii]

Habe gerade mal einen Blick auf die "Spezifikationen" von JSGI und Rack geworfen und muss sagen: Amateure. In beiden Fällen wird kein Wort über Encodings und Bytes vs. Zeichen gesagt. Das ist alles genau der gleiche Mist.

Und wenn ich das richtig sehe ist Unicode auch mit Seaside nicht ganz so trivial. Das „beruhigende“ ist ja, dass es bei Zeichensätzen eigentlich fast überall Probleme gibt. Umlaute in Dateinamen sind ja z.B. leider immer noch ein no-go wenn man betriebssystemübergreifend Dateien verwaltet.

Bei Programmiersprachen ist das auch noch nicht so ganz angekommen, Go schießt da ja aktuell imo wieder den Vogel ab. Und Pythons Unicode-Implementierung ist ja leider auch verbuggt wenn man es mit UCS16 kompiliert.