Das deutsche Python-Forum

Hallo,

seit einiger Zeit bin ich auf der Suche nach einem Web-Framework, mit dem die Arbeit Spaß macht, das keine Schmerzen verursacht und meiner Vorstellung von guter Software-Architektur entspricht. Bis jetzt habe ich das nur leider nicht gefunden.

CherryPy gefällt mir zwar wegen seiner Einfachheit und Kompaktheit, aber die Doku finde ich grausam und wenn man vom Standardschema abweichende URLs haben möchte, hört es auch einfach zu sein.

Werkzeug wurde mir schon als Ausgangspunkt empfohlen und vielleicht sollte ich mir das noch mal genauer ansehen, aber so auf den ersten Blick spricht es mich irgendwie einfach nicht an.

Pylons erscheint mir von den großen Rails-artigen Frameworks am interessantesten, aber schon einfache Sachen finde ich dort zu umständlich.

TurboGears fand ich mal sehr interessant, aber nachdem was ich so gehört habe, ist das Projekt etwas wackelig und die Zukunft fragwürdig.

Django gefällt mir wegen des ORMs nicht. Und wie bei Pylons und TurboGears auch findet die Validierung nicht (primär) in Model-Objekten statt, was ich überhaupt nicht mag. Mir gefällt der Ansatz von Grails, wo man in einer Modellklasse angibt, welche Eigenschaften die Felder des Objekts erfüllen müssen.

Sowas kompaktes wie Rubys Sinatra wäre mir eigentlich am liebsten, bloß kenne ich nichts vergleichbares für Python.

Soweit die Vorgeschichte. Ich habe mir einiges angesehen, nicht nur in der Python-Welt, und bin langsam etwas Framework-müde. Deshalb überlege ich gerade, etwas eigenes auf Grundlage von WSGI zu entwickeln. Und jetzt kommt die eigentliche Frage: Würdet ihr dafür Python 3 oder Python 2.6 nehmen? Eigentlich würde ich lieber Python 3 nehmen, aber da scheint mir die Versorgung mit Bibliotheken noch nicht wirklich gut zu sein. SQLAlchemy oder eine Template-Engine würde ich ja schon gerne einsetzen ...

Was würdet ihr machen?

Gruß
Christian

Wenn du keine Datenbank brauchst und dir dein Rahmenwerk selbst bauen willst, ist Python 3.x eine gute Wahl. Ansonsten bist du noch auf unbestimmte Zeit zu Python 2.x verdammt, da es weder mit Python 3.x kompatible Datenbank-Treiber gibt noch WSGI klaglos mit Python 3.x funktioniert. Und die etablierten Rahmenwerke nur Python 2.x unterstützen. Vergiss einfach, dass es Python 3.x gibt ;) :(

Etwas wie Sinatra kann man sich aber in der Tat schnell selbst bauen. Lässt man bei einem Web-Rahmenwerk Modelle, Validierung, Templates, Formulare und vorgefertigten Lösungen zur Produktivitätssteigerung wie Sessions, Benutzerverwaltung, Benutzerrechte, Admin-UI, RSS-Feeds, Kommentare, usw. weg, bleibt ja eigentlich nur noch ein Mechanismus, eine URL auf eine Funktion abzubilden übrig.

Siehe auch http://www.python-forum.de/topic-18972.html

Modell-Validation ist übrigens für Django 1.2 geplant. Da die Entwickler aber bereits in ihrem Plan für 1.1 einige Monate hängen, würde ich damit nicht in diesem Jahr rechnen. Hier ist aktuelle Stand: http://wiki.github.com/HonzaKral/django ... validation

Wenn du allerdings "Framework-müde" bist, finde ich die Reaktion komisch, selbst noch eines bauen zu wollen. Nimm doch einfach itty. Oder schau dir http://pythonpaste.org/webob/ an, das ist genau so primitiv, äh, flexibel und ausbaufähig.

Übrigens: Die Template-Engine (siehe mein Posting) würde ich ja in jedem Fall auch selbst bauen. Das finde ich tatsächlich auch einfacher als diesen ganzen HTTP-Krams richtig zu machen. Beim Datenbank-Zugriff habe ich mein Limit (2x für Smalltalk, 2x für Java) an ORM-Implementierungen schon erreicht und muss das nicht mehr machen ;)

Stefan

Hallo Stefan,

danke für deine Antwort. Deine Einschätzung zu Python 3 war meine Befürchtung. Eine Datenbank brauche ich zwingend und ORM finde ich eigentlich auch ganz angenehm. Also wird es wohl auf Python 2.6 hinauslaufen.

Meine Framework-Müdigkeit bezieht sich auf das ausprobieren von Frameworks. Am Anfang sieht meistens alles ganz schön aus, aber früher oder später entdeckt man die hässlichen Stellen und oft genug ist es so hässlich, dass ich es nicht mehr verwenden will. Und dann kommt das nächste Framwork und das Spiel beginnt von vorn. Bei einem eigenen Framework würde ich erstens zwangsläufig alles verstehen, weil ich es ja selbst geschrieben habe und könnte evtl. entstandene Hässlichkeiten auch leichter ausmerzen und zweitens ärgere ich mich lieber über eigene Fehler, als fremden Fehlern ausgeliefert zu sein.

Ich bin mir nur noch nicht ganz sicher, auf was ich mich da einlasse, also wie kompliziert etwa eine Sitzungsverwaltung oder ein Modul für Datei-Uploads ist. Wenn ich an SSL-Unterstützung denke, kriege ich Angst. Sowas wie das Servlet API + Unterstützung für Datei-Uploads wäre wohl ziemlich genau das, was ich suche. WebWare will sowas sein, aber da ist mir schon wieder zuviel anderes Zeug bei.

Du hast ein paar Mini-Frameworks erwähnt; kannst du mittlerweile auch etwas zu den Kandidaten sagen?

Was die Template-Engine angeht, muss ich noch mal gucken. Meiner Meinung nach sollte im Template eigentlich gar nicht so viel passieren, jedenfalls gehören Schleifen und Bedinungen eigentlich eher in ein normales Programm als in ein Template.

Gruß
Christian

deamon hat geschrieben:Ich bin mir nur noch nicht ganz sicher, auf was ich mich da einlasse,

Mal eben ein Framework zu implementieren ist zwar schnell begonnen, wird etwas später aber genauso schnell recht aufwendig.

deamon hat geschrieben:Meiner Meinung nach sollte im Template eigentlich gar nicht so viel passieren, jedenfalls gehören Schleifen und Bedinungen eigentlich eher in ein normales Programm als in ein Template.

Für solche puristische Anforderungen werfe mal einen Blick auf string.Template. Das ist ganz praktisch (und auch sehr schnell), wenn Du nur Substitution benötigst.

deamon hat geschrieben:CherryPy gefällt mir zwar wegen seiner Einfachheit und Kompaktheit, aber die Doku finde ich grausam und wenn man vom Standardschema abweichende URLs haben möchte, hört es auch einfach zu sein.

Hallo Christian!

Was die Dokumentation von CherryPy betrifft: Ich bin recht gut damit gefahren, mir alle Seiten der CherryPy-Website auszudrucken und durchzulesen. Die wichtigsten Dinge werden auf jeden Fall erklärt. Weiters habe ich noch dieses Buch http://www.cherrypyessentials.com/ gelesen. Dort steht der Rest drinnen, den man noch wissen muss.

Aber eigentlich ist CherryPy recht einfach aufgebaut. Es gibt eine Request-Objekt (``cherrypy.request``) über das man alles erfahren kann, was so vom Browser an Informationen rüber kommen. Ich habe mir dazu eine kleine Funktion geschrieben, die mir anzeigt, was ich alles so an Informationen bekomme:

Code: Alles auswählen

    def show_request(self):
        """
        Zeigt die Attribute des Requests als Text an.
        """
        from pprint import pformat
        
        retstr = "<pre>"
        for key, value in cherrypy.request.__dict__.items():
            retstr += "%s: %s\n\n" % (key, pformat(value).replace("\\n", "\n"))
        retstr += "</pre>"
        
        return retstr

Sehr nützlich das Ding!

Bei jedem Request eines Browsers wird dieser an eine Funktion weitergeleitet. Über *args und **kwargs bekommt man den Pfad und die übermittelten Parameter übergeben. Die Rückgabe dieser Funktion, wird dann direkt als Response an den Browser zurück gesendet. Der einfachheit halber, wird das Ganze als Content-Typ "text/html" übermittelt. Möchte man stattdessen einen anderen Content-Typ zurück liefern, dann kann man den Content-Typ selber ändern.

Der Response kann angepasst werden, bevor dieser an den Browser zurück gesendet wird. Der Response ist genau so ein Objekt wie der Request. Der Response ist in CherryPy über ``cherrypy.response`` ansprechbar.

Genau so wie es eine Request-Objekt und ein Response-Objekt gibt, gibt es auch ein Session-Objekt (``cherrypy.session``). Dabei handelt es sich um ein Dictionary-ähnliches Objekt, an welches man Objekte binden kann. Objekte, die für eine Session lang gültig sind. Man kann die Session so einstellen, dass diese im Dateisystem als Pickle oder in einer Datenbank abgelegt wird.

Wenn man mit Datenbanken arbeitet, dann ist noch recht fein, dass man ein threadsicheres Objekt (``cherrypy.thread_data``) zur Verfügung hat, an welches man Objekte/Daten binden kann, die immer nur für den aktuellen Thread gültig sind. So kann man je eine Connection für je einen Thread vorhalten. Das sind dann in der Standardeinstellungen neun Thread mit je einer eigenen Connection.

Die Einstellungen können in einer INI-Datei gehalten werden. Man greift über ``cherrypy.config`` darauf zu. Das kann man z.B. nutzen um die Datenbankeinstellungen auszulagern.

Über die INI-Datei kann man z.B. einstellen, dass CherryPy immer nur UTF-8 zurück liefert. Dafür muss man sich nur darum kümmern, dass man beim "return" der jeweiligen Handler-Funktionen Unicode zurück gibt. CherryPy kümmert sich um den Rest.

Weiters kann man CherryPy so einstellen, dass man beim Request Unicode (z.B. von HTML-Formularen) zurück bekommt. Man kann sich dann einfach darauf verlassen, dass man es in der Handler Funktion immer nur mit Unicode zu tun hat. Dieses Verhalten wird seit der neuen Version auch von Cheetah, der Python-ähnlichen Vorlagensprache, unterstützt.

Ich glaube, das schreibe ich so auch in meine Website.

mfg
Gerold

PS: Gesagt, getan --> http://halvar.at/python/ein_paar_worte_ueber_cherrypy/

PS2: Das mit den "komplizierteren" URLs ist auch nicht so schwer: http://www.python-forum.de/post-132770.html#132770

.

Das deutsche Python-Forum

Python 3 oder 2.6 für ein Web-Framework verwenden?

Python 3 oder 2.6 für ein Web-Framework verwenden?

Re: Python 3 oder 2.6 für ein Web-Framework verwenden?