Ein Webrahmenwerk für Python 3.x?

Du hast eine Idee für ein Projekt?
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Ein Webrahmenwerk für Python 3.x?

Beitragvon sma » Samstag 18. April 2009, 10:30

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
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Re: Ein Webrahmenwerk für Python 3.x?

Beitragvon gerold » Samstag 18. April 2009, 15:49

sma hat geschrieben: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
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Dauerbaustelle
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

Beitragvon Dauerbaustelle » Sonntag 19. April 2009, 00:43

Also falls du eines schreiben möchtest, wäre ich dabei :P
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Beitragvon sma » Sonntag 19. April 2009, 08:41

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
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

Beitragvon Dauerbaustelle » Sonntag 19. April 2009, 13:16

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ß
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Sonntag 19. April 2009, 17:53

sma hat geschrieben: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
:-)
http://halvar.at | Kleiner Bascom AVR Kurs

Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Darii
User
Beiträge: 1177
Registriert: Donnerstag 29. November 2007, 17:02

Beitragvon Darii » Sonntag 19. April 2009, 21:52

Gibt es überhaupt schon WSGI für Python 3? AFAIR gabs da Unklarheiten mit str/bytes/unicode.
tordmor
User
Beiträge: 100
Registriert: Donnerstag 20. November 2008, 10:29
Wohnort: Stuttgart

Beitragvon tordmor » Montag 20. April 2009, 07:41

Darii hat geschrieben: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
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Beitragvon sma » Mittwoch 22. April 2009, 18:26

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
Benutzeravatar
Hyperion
Moderator
Beiträge: 7472
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Beitragvon Hyperion » Mittwoch 22. April 2009, 18:32

@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
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Beitragvon sma » Mittwoch 22. April 2009, 18:42

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
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

Beitragvon Dauerbaustelle » Mittwoch 22. April 2009, 20:05

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.
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Mittwoch 22. April 2009, 22:35

Dauerbaustelle hat geschrieben: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.

Dauerbaustelle hat geschrieben: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).
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Dauerbaustelle
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

Beitragvon Dauerbaustelle » Mittwoch 22. April 2009, 23:18

Leonidas hat geschrieben:(und dann sind die URLs entsprechend fürchterlich).

Ich glaube, ich werd da mal in den nächsten Tagen was rumprobieren :-)
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Beitragvon sma » Freitag 1. Mai 2009, 22:25

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

Stefan

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder