Zumindest die großen Frameworks (Django, Python, TurboGears) sind sofort lauffähig
Nur bei Zope der Fall in der Tat kommt Zope oftmals nicht einmal mit anderen Python-Versionen zurecht.Hinzu kommt, dass im Normfall ein Python-Interpreter automatisch mitgeliefert wird, so dass dieser nicht mehr gesonder installiert werden muss.
Quatsch, wenn ich dich an einen Server setze, wirst du die Performance von mod_python und FastCGI nicht unterscheiden können.Das Einbinden von Python-Programmen über CGI oder FastCGI ist im Allgemeinen sehr langsam
Die ist gar nicht integriert, das ist ein eigenständiges Projekt.Für Python-Programm bietet sich außerdem die seit 2000 im Apache integrierte mod_python-Schnittstelle an.
Das war der Fall für TurboGears 0.7, aber TurboGears 1.0 besteht aus unzähligen weiteren Teilen. Wobei ich gehört habe, dass die irgendwann auf SQLAlchemy und Genshi umsteigen wollen.TurboGears ist aus den folgenden vier grundlegenden nicht-full-stack Framweworks aufgebaut
TurboGears hat Version 1.0.1 erreicht, das bedeutet dass es eher keine Beta ist. Django mit 0.95.1 würde ich ebenfalls nicht als Beta-Version bezeichnen, weil das ein pre-1.0 und kein Betarelease ist.TurboGears und Django liegen aktuell noch als Beta-Version vor, das Arbeiten mit ihnen ist aber bereits sehr gut möglich.
sind die anderen, kleineren Frameworks. So hätte ich gerne etwas neues über das Metaframework Paste gelesen, über die WSGI-Ebene Paste, über das gute alte Webware, etc.rafael hat geschrieben:Was mir bei dem Artikel fehlt,
Hi!BlackJack hat geschrieben:Karrigell wird in comp.lang.python auch öfter angepriesen.
Natürlich - denn Colubrid strebt eine saubere Lösung an. Und einen Python-HTTP-Server zu benutzen, um Mediendaten auszuliefern ist praktisch - aber nicht besonders performant. Es gibt aber für WSGI "static" zum nachrüsten.jens hat geschrieben:Leider liefert der allerdings keine Statischen Dateien aus, das ist echt schade
Daher kannst dun static problemlos integrieren. Warum willst du, dass Colubrid die Funktionalität von "static" kopiert? Macht doch keinen Sinn und ist eigentlich auch das Gegenteil von WSGI.jens hat geschrieben:Bei mir geht es dabei allerdings nicht um die Performance... Der Entwicklungs-Server ist eh nicht für den Produktiven Einsatz gedacht...
Ich mache das immer so (allerdings mit Django, was aber aufs gleiche kommt, denn Django bietet auch einen Entwicklungsserver mit autoreloading und ohne statische Dateien), dass ich einen extra-VHost habe mit einer eigenen Domain und dort die Mediadaten interlegt habe. Diese Domain wird nun vom Produktivserver direkt gehostet und im HTML-Code sind die Links alle auf den Mediaserver. Somit habe ich sowohl den Entwicklungsserver als auch statische Dateien. Ohne größere Scherereien. Als ich darauf gekommen bin, wie elegant diese Lösung ist musste ich zugeben, dass die Django-Entwickler wieder einmal mitgedacht haben. Und das lässt sich natürlich ebenso auf Colubrid übertragen.jens hat geschrieben:Ich entwickel aber z.B. eine Gallerie-Plugin für PyLucid... Die kann ich mit dem colubrid Server allerdings nicht gut testen, weil die Bilder/Thumbnails nicht ausgeliefert werden...
Code: Alles auswählen
if settings.DEBUG:
urlpatterns += patterns('',
(r'^m/(?P<path>.*)$', 'django.views.static.serve', {'document_root':join(VERZEICHNIS, 'media')}),
)
MfG apollo13The big, fat disclaimer
Using this method is inefficient and insecure. Do not use this in a production setting. Use this only for development.
For information on serving static files in an Apache production environment, see the Django mod_python documentation.
Code: Alles auswählen
if settings.DEBUG: