Ein Webrahmenwerk für Python 3.x?

[sma]

Hat jemand, kennt jemand oder hat jemand Lust es zu schreiben? Ich hätte gerne ein WSGI-basiertes minimales Webrahmenwerk für Python 3.x. Einfachheit geht vor Praxistauglichkeit. Wenn man damit einen Blog, Twitterclone oder das nächste coole Browser-Game schreiben kann, reicht mir das völlig ;) Vielleicht etwas wie Sinatra für Ruby?

Ich hätte es gerne als ein Beispiel für mein Smython-Projekt, damit ich auf ein konkretes Ziel hin arbeiten kann. Meine Vision ist da immer noch, mit Hilfe von Smython ein Python 3-Programm auf der Google App Engine laufen lassen zu können.

Stefan

[gerold]

Ich hätte gerne ein WSGI-basiertes minimales Webrahmenwerk für Python 3.x.

Hallo Stefan!

Es gibt einen Python3-Branch von CherryPy. Allerdings weiß ich nicht, ob das Ding schon halbwegs benutzbar ist.

http://cherrypy.org/browser/branches/python3

lg
Gerold

[Dauerbaustelle]

Also falls du eines schreiben möchtest, wäre ich dabei :P

[sma]

Ich vermute mal, CherryPy ist nicht nur ein Standalone-Server, sondern könnte auch per WSGI angesprochen werden. Aus einer Minute auf das SVN zu starren wird mir aber diese Trennung nicht klar. Daher hätte ich eigentlich gerne lieber etwas Minimales.

Idealerweise wären da keine Metaklassen, kein __slots__, kein Zugriff auf irgendwelche __-Methoden von Fuktionen oder Klassen, kein yield, keine Floats (obwohl, das wäre nur Fleißarbeit, die einzuführen), möglichst wenig Bibliotheksfunktionen und natürlich keine Abhängigkeiten zu C-Modulen.

Dauerbaustelle, falls du mit "du" mich meinst: Ich wollte eigentlich gerne anderen diese Arbeit überlassen. Aber ich bin neugierig: Hast du bestimmte Vorstellungen?

Die üblichen Bestandteile sind ja etwas, das Requests zugänglich macht und erlaubt, einfacher Responses zu generieren. Etwas, das URLs auf Funktionen abbildet und etwas, das hilft, HTML zu generieren. Dazu hätte ich gerne noch eine optionale Session-Verwaltung. Nett wäre noch eine Persistenzschicht, doch da ich auf die Google App Engine ziele, wäre diese recht speziell. Anderseits: Die Java-Version mappt diese ja per JDO oder JPA und letzteres ist schon wieder fast relational.

Stefan

[Dauerbaustelle]

sma, naja, quasi ein Werkzeug in klein: Ein dünner Wrapper über dem Low-Level-Zeug wie einem HTTP-Server und WSGI, der das Model-View-Controller-Paradigma verfolgt (besser wohl Model-View-Template).

Der Ablauf eines Requests wäre dann etwa so:
HTTP-Request kommt rein -> wird erst mal in Request-Klasse umgewandelt -> Requests wird gedispatcht und die entsprechende Funktion (view) wird aufgerufen -> View macht Zeugs damit, gibt ein Response-Objekt zurück (welches davor ggf. durch ein Template erzeugt wurde). Und das wars.

Das ist zwar mehr oder weniger das, was Werkzeug macht, aber da muss man zum Beispiel noch von der WSGI-Klasse erben und so Kram wie die Localmanager machen, das wöllte ich nicht, das nervt.

Die Einfachheit von Django, beschränkt auf die Features von oben, ohne dieses elendige Regular-Expressions-URL-Konfigurieren. Allgemein erstmal ohne Konfigurieren.

Gruß

[gerold]

Ich vermute mal, CherryPy ist nicht nur ein Standalone-Server, sondern könnte auch per WSGI angesprochen werden.

Hallo Stefan!

Eine CherryPy-Application ist eine WSGI-Application. Diese kann z.B. mit mod_wsgi direkt angesprochen werden.
Siehe: http://code.google.com/p/modwsgi/wiki/I ... thCherryPy

lg
Gerold

[Darii]

Gibt es überhaupt schon WSGI für Python 3? AFAIR gabs da Unklarheiten mit str/bytes/unicode.

[tordmor]

Gibt es überhaupt schon WSGI für Python 3? AFAIR gabs da Unklarheiten mit str/bytes/unicode.

Es gibt keine Unklarheiten. Lediglich die Referenzimplementierung war falsch weil nicht portiert. Meines wissens kann das neue mod_wsgi mit python 3 verwendet werden.

Gibt es eigentlich noch kein Bestreben Werkzeug auf py3 zu übersetzen? Man kann ja alles weg lassen, was man nicht braucht.

[sma]

Dauerbaustelle, du beschreibst, was auch ich mir vorstellen kann. Ich glaube, wir beide wollen aber ein vorkonfektioniertes Rahmenwerk und nicht nur eine lose Sammlung von Funktionen. Mir den regulären Ausdrücken von Django habe ich nicht so die Probleme, das alte Controller-View-ID-Prinzip von Rails 1.x kann es aber meinetwegen auch sein.

Gerold, bei CherryPy ist mir zu viel Programmcode. Was ich versuchte zu sagen: Ich erkenne nicht, was CherryPy, das WSGI-Rahmenwerk und was CherryPy, der Standalone-HTTP-Server ist. Und dann gibt es glaube ich noch CherryPy, die Template-Sprache.

Ich sage mal: Das ganze Rahmenwerk sollte idealerweise in 1024 Zeilen Programmcode passen und keine externen Abhängigkeiten haben. Dann habe ich eine Chance, meinen Python-Interpreter darauf zu trimmen.

Werkzeug oder WebOb man mit 2to3 zu bearbeiten und zu schauen, was da noch so über bleibt wäre ansonsten eine interessante Alternative.

Stefan

[Hyperion]

@sma & Dauerbaustelle:
Habt ihr beide denn ein Framework, welches ihr unter 2.x gut findet? Wenn ja, heißt es ja nur ein wenig Geduld aufbringen, bis das auf 3.x portiert ist

Ich sehe keinen Vorteil / Anreiz darin, gerade jetzt etwas für 3.x neu zu entwickeln, wo es doch schon zig Frameworks gibt, die sicherlich im Laufe der Zeit auch nach 3.x portiert werden!

Sollten werkzeug, jinja2 und sqlalchemy schon unter 3.x laufen, dann wäre Glashammer evtl. eine Option - obwohl ich es mir nicht so genau angeguckt habe, verwendet das ja drei sehr beliebte Komponenten.

[sma]

Mir gefällt Django. Allerdings war meine Motivation, ein Beispiel zu haben, das ich mit meinem eigenen Python-Interpreter zum Laufen bekommen. Ein potentielles 3.x-kompatibles Django ist dafür viel zu groß und damit fällt das raus. Und ich wollte gerne, dass nicht ich das machen muss, weil schon die verrückte Idee, mal eben einen Python-Interpreter bauen zu wollen, zu viel Zeit in Anspruch nimmt ;)

Für Jinja2 und SqlAlchemy gilt übrigens auch das "zu groß"-Argument...

Stefan

[Dauerbaustelle]

Django ist gut und Werkzeug schnell, bei sind aber elendig aufwändig (ZU aufwändig) zu konfigurieren. Ich habe keine Lust, wenn ich eine Webanwendung schreiben will, einen Großteil der Zeit mit URLs oder so Kram zu verbringen.

[Leonidas]

Django ist gut und Werkzeug schnell, bei sind aber elendig aufwändig (ZU aufwändig) zu konfigurieren.

Deswegen gibt es auch ein Werkzeug-basiertes Framework.

Ich habe keine Lust, wenn ich eine Webanwendung schreiben will, einen Großteil der Zeit mit URLs oder so Kram zu verbringen.

Ich weiß nicht, also meine URLconfs fasse ich vielleicht dreimal im Jahr an, sonst nie. Also sich noch weniger um URLs kümmern geht kaum noch, ohne URLs autogenerieren zu lassen (und dann sind die URLs entsprechend fürchterlich).

[Dauerbaustelle]

(und dann sind die URLs entsprechend fürchterlich).

Ich glaube, ich werd da mal in den nächsten Tagen was rumprobieren :-)

[sma]

Kurzer Nachtrag: Ich habe jetzt mal mit einem eigenen Wicket-artigen komponenten-basierten Rahmenwerk experimentiert.

Stefan