Python und Webprogrammierung [neuling]

[jens]

Im übrigen hab ich mal ein kleines HelloWorld-Tutorial mit WSGI/Colubrid im Wiki erstellt: [wiki]Colubrid/Hello World[/wiki]

IMHO sollte kein oder nur ganz wenig Python-Code in einem Template sitzten... Höchstens kleinigkeiten für eine Schleifenbearbeitung...

[mitsuhiko]

Ich denke wenn man es für den Anfang einfach haben will, so ähnlich wie PHP, dann sollte man mit CGI anfangen.

Sollte man nicht.

Sollte man doch. Was bleibt denn anderes übrig wenn man partout keine Webframeworks verwenden möchte? Diese Anforderung stammt ja nicht von mir.

Wer sagt den, dass man für WSGI ein Framework verwenden muss? Muss man genauso wenig wie für CGI

Für eine CGI Anwendung muss man in der Regel viel nervtötendes erledigen. Beispielsweise multipart requests parsen...

Echt!? Man muss multipart requests parsen? Musste ich bis jetzt noch in keinem CGI Skript machen.

Noch nie mit Dateiuploads gearbeiten? Und wenn du meinst, dass du mal schnell ein Cookie Handling mit CGI machst endet das nunmal in einem etwas längeren Skript. Header nach dem Content senden bearbeiten? Ist auch lustig mit CGI. Muss mal halt einen Buffer machen. Geht auch alles, aber da kann ich auch gleich WSGI nehmen...

Python lässt sich wegen der Syntax (Einrückung bestimmt Programmstruktur) nicht so einfach in HTML einbetten,...

Ney. Das stimmt so nicht. Python lässt sich genauso gut in HTML Code einbetten wie PHP auch. Beispiele dafür sind PSP, Cheetah, Spyce und andere.

Doch das stimmt so. Ich sagte nicht das es unmöglich ist, sondern nur nicht so einfach. Darum gibt's bei vielen Template-Modulen nur "eingeschränktes" Python. Wenn die Einrückungstiefe wichtig ist, dann kann man eben nicht so einfach HTML und Python mischen. Wenn man dann noch die Datei mal in einem WYSIWYG HTML-Editor bearbeitet dann kann man Probleme bekommen, die man bei PHP nicht hätte.

Du hast nicht wirklich eine Ahnung von was du redest oder? Das mit Python Code in HTML hat absolut nichts mit der Einrückung oder ähnlichem zu tun. Und das viele Tempalte Engines nur ein Subset von Python kennen hat noch weniger mit der Einrückung oder sowas zu tun. Für Jinja beispielseweise habe ich absichtlich interpretierende Templates, weil python in templates nicht mal im Ansatz so praktisch ist wie eine überlege Tempalte Sprache, die ihre eigene Syntax mitbringt.

Also sehe wir uns mal die Python Templates an, die es gibt. Da hätten wir mal zu allererst PSP. Unterstützt Python ausnahmslos. Weiter gehts mit spyce. Auch wie denkt die Template engine den kompletten Python Sprachbereich ab, den es gibt. Cheetah? Auch in diesem Fall haben wir Zugriff auf den ganzen Sprachgebraucht, aber hier schon leichte Ansätze von Template spezifischen Funktionen. Weiter gehts mit kid. Trotz XML Ansatz auch hier kompletten Zugriff auf alle Python Funktionen. Jinja, hier ist genauso wie bei django templates, SimpleTAL, HTMLTemplate, pyTempl, Spytee und Nevow eine eigene Syntax mit eigenen davorgeschalteten Interpreter bzw einer Klasse, die in Python Code umwandelt. Und wenn man auf PHP schaut sieht man, dass die PHP Entwickler auch lieber diesen Weg wählen, Smarty ist hier das Beste Beispiel.

Und nein. Das hat alles nichts mit der Einrückung zu tun

Da es guter Stil ist Logik und Präsentation zu trennen empfinde ich diese Einschränkung aber eher als Vorteil.

Da stimme ich dir zu, aber nur in der Hinsicht, dass die Trenung gut ist. denn die Einschränkung sehe ich nicht.

[N317V]

Erstmal vielen Dank BlackJack und vor allem blackbird! Das bringt schon ein wenig mehr Licht ins Dunkel. Das Problem ist IMHO einfach, dass man eine einfach Frage zu Webentwicklung stellt und gleich mit einem Arsenal an Schlagwörtern und zugehörigen Ratschlägen und/oder Warnungen erschlagen wird. Seht Euch doch nochmal den Eingangspost an! banthrass geht es ähnlich wie mir und wohl auch vielen anderen:

1. Ich hab einen funktionstüchtigen Webserver (Apache), mit dem ich sehr zufrieden bin. Ich will keinen zweiten Webserver, keinen weiteren Port aufmachen, nichts dergleichen.
2. Ich kann und will mich nicht durch die Dokumentation von 10 oder 20 verschiedenen Frameworks, Middlewares oder sonstwas arbeiten. Ich kann und will auch nicht jedes mal testweise installieren um dann zu sehen, dass es doch nicht das richtige war. Ich will überhaupt nur was installieren, wenn es unbedingt nötig ist. Python hab ich ja schon und Apache auch. Wenn ich noch was brauche, kommt automatisch die Frage "Wofür?" und wenn die Antwort darauf länger als eine Minute erfordert, brauch ich es wahrscheinlich nicht. Ich will keine Lösungen für Probleme, die ich noch gar nicht hab.
3. Ich will, dass Apache auf Anfrage irgendwie (wie, ist mir ersteinmal völlig egal) ein Python-Script startet und dessen Output als Antwort auf die Anfrage zurückgibt. Dass man das dann noch aufbohren und/oder vereinfachen kann ist mir vollkommen klar. Darüber mach ich mir dann später Gedanken! Wenn ich das jetzt richtig verstanden habe, brauch ich dafür einen wrapper.
4. (Gilt für banthrass möglicherweise nicht) Ich will eine saubere Trennung von Logik und Präsentation. Kein Code im Template!

Kurz gesagt, das Problem ist: Ich finde einfach keinen Anfang in all dem Wirrwarr. Womit *muss* ich mich näher beschäftigen? Was *kann* ich mir ansehen, wenn meine Anforderungen steigen?

EDIT: Danke auch an jens für das Beispiel im Wiki! Langsam wird es in dieser Richtung heller

[jens]

OK, du kannst natürlich, wie ich es auch gemacht hab, einfach nur pure-Python-CGI benutzten... Alles selber machen usw.... Das ist ja auch nicht schlimm, meine Webseiten laufen mit PyLucid als CGI ganz nett...
Nur das dumme an CGI ist, das es langsam wird, wenn mehr Traffic da ist, weil der Python-Interpreter für jeden Request/Client einzeln gestartet wird... Somit eine recht große Belastung für den Server...
Mit WSGI hast du allerdings später die Möglichkeit was anderes als CGI, also modPython, fastCGI ect. zu nutzten. Dafür brauchst du deine Anwenung i.d.R. nicht umschreiben. Das ist der große Vorteil.

Anfangen kannst du ja mit WSGI auch als normales CGI. Siehe [wiki]Colubrid/Hello World[/wiki]
Du hast später aber mehr Möglichkeiten mehr zu machen, wenn du von anfang an auf WSGI setzt...

[tabellar]

...
1. Ich hab einen funktionstüchtigen Webserver (Apache), mit dem ich sehr zufrieden bin. Ich will keinen zweiten Webserver, keinen weiteren Port aufmachen, nichts dergleichen.
2. Ich kann und will mich nicht durch die Dokumentation von 10 oder 20 verschiedenen Frameworks, Middlewares oder sonstwas arbeiten. Ich kann und will auch nicht jedes mal testweise installieren um dann zu sehen, dass es doch nicht das richtige war. Ich will überhaupt nur was installieren, wenn es unbedingt nötig ist. Python hab ich ja schon und Apache auch. Wenn ich noch was brauche, kommt automatisch die Frage "Wofür?" und wenn die Antwort darauf länger als eine Minute erfordert, brauch ich es wahrscheinlich nicht. Ich will keine Lösungen für Probleme, die ich noch gar nicht hab.
3. Ich will, dass Apache auf Anfrage irgendwie (wie, ist mir ersteinmal völlig egal) ein Python-Script startet und dessen Output als Antwort auf die Anfrage zurückgibt. Dass man das dann noch aufbohren und/oder vereinfachen kann ist mir vollkommen klar. Darüber mach ich mir dann später Gedanken! Wenn ich das jetzt richtig verstanden habe, brauch ich dafür einen wrapper.
4. (Gilt für banthrass möglicherweise nicht) Ich will eine saubere Trennung von Logik und Präsentation. Kein Code im Template!

Ok, nochmal zurück zu den Anfängen... Um bei Deinem laufenden System ein Python Skript zu starten, ist dies wohl die einfachste Art...

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: utf-8 -*-

print "Content-type: text/html"
print ""

print "Hello World!"

Den gezeigten Code als Datei helloWorld.py speichern und in das cgi-bin Verzeichnis vom Apache speichern. Mit dem Aufruf http://localhost/cgi-bin/helloWorld.py solltest Du dann das "Hello World!" sehen (Dateirechte beachten!).

Tabellar

PS:
Darauf kann man dann all die tollen Dinge von oben aufbauen...

[N317V]

@tabellar:

Traumhaft! Ich wusste doch, dass es einfach ist! Genau das muss die allererste Antwort auf die Frage nach Python im Web sein. banthrass hatte ja auch geschrieben, dass er "Neuling" ist. Als Zweites kann dann IMHO der Hinweis auf unterschiedliche Interfaces, somit WSIG und schließlich Colubrid kommen.

Leicht OT: Was ist Colubrid eigentlich für ein komischer Name?

[mitsuhiko]

Traumhaft! Ich wusste doch, dass es einfach ist! Genau das muss die allererste Antwort auf die Frage nach Python im Web sein. banthrass hatte ja auch geschrieben, dass er "Neuling" ist. Als Zweites kann dann IMHO der Hinweis auf unterschiedliche Interfaces, somit WSIG und schließlich Colubrid kommen.

Colubrid == WSGI kompatibel. WSGI ist nur das, was du auch gerade oben mit dem kleinen Skript gemacht hast, nur halt mit mehr System dahinter.

Leicht OT: Was ist Colubrid eigentlich für ein komischer Name?

http://en.wikipedia.org/wiki/Colubrid

zu Deutsch auch Natter

[BlackJack]

Ich denke wenn man es für den Anfang einfach haben will, so ähnlich wie PHP, dann sollte man mit CGI anfangen.

Sollte man nicht.

Sollte man doch. Was bleibt denn anderes übrig wenn man partout keine Webframeworks verwenden möchte? Diese Anforderung stammt ja nicht von mir.

Wer sagt den, dass man für WSGI ein Framework verwenden muss? Muss man genauso wenig wie für CGI

Na dann halt WSGI. (Ich gehe jetzt mal davon aus das Colubrid und web.py WSGI ohne viel Framework drumherum anbieten!?)

Echt!? Man muss multipart requests parsen? Musste ich bis jetzt noch in keinem CGI Skript machen.

Noch nie mit Dateiuploads gearbeiten?

Nein.

Und wenn du meinst, dass du mal schnell ein Cookie Handling mit CGI machst endet das nunmal in einem etwas längeren Skript.

Das ändert sich mit WSGI? Cookies und Sessions sind da auch nicht dabei.

Header nach dem Content senden bearbeiten? Ist auch lustig mit CGI. Muss mal halt einen Buffer machen. Geht auch alles, aber da kann ich auch gleich WSGI nehmen...

Ist auch unheimlich schwer `StringIO` zu importieren um die Daten zwischen zu speichern.

Python lässt sich wegen der Syntax (Einrückung bestimmt Programmstruktur) nicht so einfach in HTML einbetten,...

Ney. Das stimmt so nicht. Python lässt sich genauso gut in HTML Code einbetten wie PHP auch. Beispiele dafür sind PSP, Cheetah, Spyce und andere.

Doch das stimmt so. Ich sagte nicht das es unmöglich ist, sondern nur nicht so einfach. Darum gibt's bei vielen Template-Modulen nur "eingeschränktes" Python. Wenn die Einrückungstiefe wichtig ist, dann kann man eben nicht so einfach HTML und Python mischen. Wenn man dann noch die Datei mal in einem WYSIWYG HTML-Editor bearbeitet dann kann man Probleme bekommen, die man bei PHP nicht hätte.

Du hast nicht wirklich eine Ahnung von was du redest oder? Das mit Python Code in HTML hat absolut nichts mit der Einrückung oder ähnlichem zu tun. Und das viele Tempalte Engines nur ein Subset von Python kennen hat noch weniger mit der Einrückung oder sowas zu tun.

Woran liegt es dann?

Also sehe wir uns mal die Python Templates an, die es gibt. Da hätten wir mal zu allererst PSP. Unterstützt Python ausnahmslos. Weiter gehts mit spyce. Auch wie denkt die Template engine den kompletten Python Sprachbereich ab, den es gibt.

Zu PSP kann ich nix sagen, aber bei Spyce bekommst Du Probleme weil ``[[`` und ``]]`` für HTML-Editoren keine besondere Bedeutung haben. Wenn das irgendwo im Text steht und nicht zufällig in `<pre>` Tags, kann einem ein WYSIWYG-Editor Probleme bereiten.

Cheetah? Auch in diesem Fall haben wir Zugriff auf den ganzen Sprachgebraucht, aber hier schon leichte Ansätze von Template spezifischen Funktionen. Weiter gehts mit kid. Trotz XML Ansatz auch hier kompletten Zugriff auf alle Python Funktionen.

Okay, meine beiden Favoriten. Fangen wir bei Cheetah an: wo bitteschön siehst Du Python in den Templates? Das ist eine eigene, zugegebenermassen sehr Python-ähnliche Sprache, die erst in Python übersetzt wird. Unter anderem gibt es für die ganzen "Blöcke" wie ``#if``, ``#for`` usw. die zugehörigen ``#end`` Schlüsselwörter eben genau um das Problem zu umgehen, dass man in einem Template nicht auf signifikante Einrückung angewiesen sein möchte.

Bei `kid` kann man ganz gut Python Quelltext unterbringen, da ist die Ausgabe von "Text" aber viel restriktiver als bei PHP. Man kann nicht einfach so Text ausgeben sondern nur gültiges XML einfügen. IMHO für eine XML-Template Sprache eine sehr nützliche "Einschränkung".

Jinja, hier ist genauso wie bei django templates, SimpleTAL, HTMLTemplate, pyTempl, Spytee und Nevow eine eigene Syntax mit eigenen davorgeschalteten Interpreter bzw einer Klasse, die in Python Code umwandelt. Und wenn man auf PHP schaut sieht man, dass die PHP Entwickler auch lieber diesen Weg wählen, Smarty ist hier das Beste Beispiel.

Hm, also kann man bei den Template Mechanismen in dem Absatz keinen Python Quelltext wie in PHP einfügen. Die unterstützen also mein Ausgangsargument. Danke.

Da es guter Stil ist Logik und Präsentation zu trennen empfinde ich diese Einschränkung aber eher als Vorteil.

Da stimme ich dir zu, aber nur in der Hinsicht, dass die Trenung gut ist. denn die Einschränkung sehe ich nicht.

Schön für Dich. Leute die von PHP kommen und Smarty schon so komisch umständlich empfanden, sehen das aber als Einschränkung.

[mitsuhiko]

Ich denke wenn man es für den Anfang einfach haben will, so ähnlich wie PHP, dann sollte man mit CGI anfangen.

Sollte man nicht.

Sollte man doch. Was bleibt denn anderes übrig wenn man partout keine Webframeworks verwenden möchte? Diese Anforderung stammt ja nicht von mir.

Wer sagt den, dass man für WSGI ein Framework verwenden muss? Muss man genauso wenig wie für CGI

Na dann halt WSGI. (Ich gehe jetzt mal davon aus das Colubrid und web.py WSGI ohne viel Framework drumherum anbieten!?)

Ja.

Und wenn du meinst, dass du mal schnell ein Cookie Handling mit CGI machst endet das nunmal in einem etwas längeren Skript.

Das ändert sich mit WSGI? Cookies und Sessions sind da auch nicht dabei.

Ja und? Aber dank dem Middleware Konzept kannst du einfach mehrere Teile aneinanderreihen und du hast Cookie/Session Handling. Und da gibts bereits mehr als genug fertige Konzepte...

Also sehe wir uns mal die Python Templates an, die es gibt. Da hätten wir mal zu allererst PSP. Unterstützt Python ausnahmslos. Weiter gehts mit spyce. Auch wie denkt die Template engine den kompletten Python Sprachbereich ab, den es gibt.

Zu PSP kann ich nix sagen, aber bei Spyce bekommst Du Probleme weil ``[[`` und ``]]`` für HTML-Editoren keine besondere Bedeutung haben. Wenn das irgendwo im Text steht und nicht zufällig in `<pre>` Tags, kann einem ein WYSIWYG-Editor Probleme bereiten.

Und das hat natürlich mit der Einrückung zu tun

Cheetah? Auch in diesem Fall haben wir Zugriff auf den ganzen Sprachgebraucht, aber hier schon leichte Ansätze von Template spezifischen Funktionen. Weiter gehts mit kid. Trotz XML Ansatz auch hier kompletten Zugriff auf alle Python Funktionen.

Okay, meine beiden Favoriten. Fangen wir bei Cheetah an: wo bitteschön siehst Du Python in den Templates? Das ist eine eigene, zugegebenermassen sehr Python-ähnliche Sprache, die erst in Python übersetzt wird. Unter anderem gibt es für die ganzen "Blöcke" wie ``#if``, ``#for`` usw. die zugehörigen ``#end`` Schlüsselwörter eben genau um das Problem zu umgehen, dass man in einem Template nicht auf signifikante Einrückung angewiesen sein möchte.

Ja logisch. Aber es ist doch scheiß egal ob du für deine Syntax jetzt #if und #end hast, oder ob du <?php if () { ?> und <?php } ?> hast. Aber ich hab Zugriff auf die komplette Sprache von Pyhton, was übrigens keine "python ähnliche Sprache", sondern Python ist.

Aber wenn du willst schreib dir eine Sprache, die Einrückungen haben will

Bei `kid` kann man ganz gut Python Quelltext unterbringen, da ist die Ausgabe von "Text" aber viel restriktiver als bei PHP. Man kann nicht einfach so Text ausgeben sondern nur gültiges XML einfügen. IMHO für eine XML-Template Sprache eine sehr nützliche "Einschränkung".

PHP ist KEINE XML Template Sprache. PHP ist nichtmal eine brauchbare Template Engine. Smarty gibts ja nicht ohne Grund.

Jinja, hier ist genauso wie bei django templates, SimpleTAL, HTMLTemplate, pyTempl, Spytee und Nevow eine eigene Syntax mit eigenen davorgeschalteten Interpreter bzw einer Klasse, die in Python Code umwandelt. Und wenn man auf PHP schaut sieht man, dass die PHP Entwickler auch lieber diesen Weg wählen, Smarty ist hier das Beste Beispiel.

Hm, also kann man bei den Template Mechanismen in dem Absatz keinen Python Quelltext wie in PHP einfügen. Die unterstützen also mein Ausgangsargument. Danke.

Ganz ehrlich hab ich die Schnauze voll mit dir zu Diskuttieren. Ich will dir nur sagen, dass wirklich durchdachte Template Engines _Keinen_ Zugriff auf Sprachelemente bieten. Alleine schon wegen der Sicherheit.

Da es guter Stil ist Logik und Präsentation zu trennen empfinde ich diese Einschränkung aber eher als Vorteil.

Da stimme ich dir zu, aber nur in der Hinsicht, dass die Trenung gut ist. denn die Einschränkung sehe ich nicht.

Schön für Dich. Leute die von PHP kommen und Smarty schon so komisch umständlich empfanden, sehen das aber als Einschränkung.[/quote]
Das sind dann die Leute, die das Konzept von Code/Template Trennung nicht verstanden haben.

[XT@ngel]

Ganz ehrlich hab ich die Schnauze voll mit dir zu Diskuttieren

Soviel zum Thema; - Vergleich Äpfel mit Birnen
Wenn man keinen eigenen Server hat ist man mit Python beim Theme Webentwicklung recht eingeschränkt und daran ändert auch WSGI nichts.

Da kann es noch soviel an Frameworks und Application Server geben am Ende muss ich mein Script doch als cgi beim billig provider laufen lassen

PSP, Django Turbogears, python-cgi, mod_python, Zope - und ich wollt nur ein Gästebuch


MfG
Andreas

[BlackJack]

Und wenn du meinst, dass du mal schnell ein Cookie Handling mit CGI machst endet das nunmal in einem etwas längeren Skript.

Das ändert sich mit WSGI? Cookies und Sessions sind da auch nicht dabei.

Ja und?

Du hattest CGI unter anderem mit dem Argument abgelehnt, dass man dort Cookies selbst verwalten muss und stattdessen WSGI vorgeschlagen. Nur das man dort Cookies auch selbst verwalten muss.

Zu PSP kann ich nix sagen, aber bei Spyce bekommst Du Probleme weil ``[[`` und ``]]`` für HTML-Editoren keine besondere Bedeutung haben. Wenn das irgendwo im Text steht und nicht zufällig in `<pre>` Tags, kann einem ein WYSIWYG-Editor Probleme bereiten.

Und das hat natürlich mit der Einrückung zu tun

Ja. Ein HTML-Editor darf Text, der zum Beispiel nur in <p> Tags steht, als "Fliesstext" umformatieren. Python-Quelltext überlebt das nicht. Wegen der signifikanten Einrückung.

Fangen wir bei Cheetah an: wo bitteschön siehst Du Python in den Templates? Das ist eine eigene, zugegebenermassen sehr Python-ähnliche Sprache, die erst in Python übersetzt wird. Unter anderem gibt es für die ganzen "Blöcke" wie ``#if``, ``#for`` usw. die zugehörigen ``#end`` Schlüsselwörter eben genau um das Problem zu umgehen, dass man in einem Template nicht auf signifikante Einrückung angewiesen sein möchte.

Ja logisch. Aber es ist doch scheiß egal ob du für deine Syntax jetzt #if und #end hast, oder ob du <?php if () { ?> und <?php } ?> hast.

Natürlich ist das egal. Eben um das zu ermöglichen benutzt Cheetah kein Python sondern eine eigene Sprache.

Aber ich hab Zugriff auf die komplette Sprache von Pyhton, was übrigens keine "python ähnliche Sprache", sondern Python ist.

Das was man in Cheeta Templates einbettet ist kein Python. Versuch mal den Python-Interpreter ``#if $foo`` ausführen zu lassen. Und ``#repeat`` oder ``#unless`` gibt's in Python auch nicht als Schlüsselworte, nicht mal ohne das führende '#'.

Aber wenn du willst schreib dir eine Sprache, die Einrückungen haben will

Häh? Will ich nicht.

Bei `kid` kann man ganz gut Python Quelltext unterbringen, da ist die Ausgabe von "Text" aber viel restriktiver als bei PHP. Man kann nicht einfach so Text ausgeben sondern nur gültiges XML einfügen. IMHO für eine XML-Template Sprache eine sehr nützliche "Einschränkung".

PHP ist KEINE XML Template Sprache.

Hat das jemand behauptet?

PHP ist nichtmal eine brauchbare Template Engine. Smarty gibts ja nicht ohne Grund.

Sehe ich auch so.

Jinja, hier ist genauso wie bei django templates, SimpleTAL, HTMLTemplate, pyTempl, Spytee und Nevow eine eigene Syntax mit eigenen davorgeschalteten Interpreter bzw einer Klasse, die in Python Code umwandelt.

Hm, also kann man bei den Template Mechanismen in dem Absatz keinen Python Quelltext wie in PHP einfügen. Die unterstützen also mein Ausgangsargument. Danke.

Ganz ehrlich hab ich die Schnauze voll mit dir zu Diskuttieren. Ich will dir nur sagen, dass wirklich durchdachte Template Engines _Keinen_ Zugriff auf Sprachelemente bieten. Alleine schon wegen der Sicherheit.

Da bin ich ganz Deiner Meinung.

Da es guter Stil ist Logik und Präsentation zu trennen empfinde ich diese Einschränkung aber eher als Vorteil.

Da stimme ich dir zu, aber nur in der Hinsicht, dass die Trenung gut ist. denn die Einschränkung sehe ich nicht.

Schön für Dich. Leute die von PHP kommen und Smarty schon so komisch umständlich empfanden, sehen das aber als Einschränkung.

Das sind dann die Leute, die das Konzept von Code/Template Trennung nicht verstanden haben.

Ebenfalls ganz Deiner Meinung.

[N317V]

Ganz ehrlich hab ich die Schnauze voll mit dir zu Diskuttieren

Soviel zum Thema; - Vergleich Äpfel mit Birnen
Wenn man keinen eigenen Server hat ist man mit Python beim Theme Webentwicklung recht eingeschränkt und daran ändert auch WSGI nichts.

Da kann es noch soviel an Frameworks und Application Server geben am Ende muss ich mein Script doch als cgi beim billig provider laufen lassen

PSP, Django Turbogears, python-cgi, mod_python, Zope - und ich wollt nur ein Gästebuch


MfG
Andreas

Und ich hab auch jemanden gefunden, der meiner Meinung ist.
Ich liebe das Internet!

[tabellar]

Leute, Leute, lasst doch die Kirche im Dorf . Jeder bringt hier sein Wissen bestmöglich mit ein. Diskutieren und Enthusiasmus sind ja schön und gut, aber
der rote Faden und der entsprechende Ton sollten nicht verloren gehen ...

Tabellar

[synopia]

Auch auf die Gefahr hin, dass ich mir ein paar Feinde hier im Python-Forum mache, schreib ich jetzt mal hier Meinung hin

...Naja da denk ich mir "warum PHP wenn ich python was neues lernen kann, was den selben effekt hat...

Ok, also ist es dir erstmal grundsätzlich egal, welche Skriptsprache du einsetzten willst, nur nicht PHP (was ich im ürbigen vollkommen verstehen kann )

...Ich hab bisher ein grundlegendes Verständnissproblem bei python. Kann mir jemand sagen wie ich python in HTML einbinden kann? Wie könnte ich z.B. einen Adminpanel für meine seite realisieren? Gibt es eine ähnliche inculde funktion wie in PHP? Kann ich python ganz nomal in einem texteditor einfügen, die page hochladen und es läuft oder ist das ein spezielles Format gefragt? Wenn ja wie binde ich dieses Format oder diese Datein ein? Es wäre nett wenn mir jemand die grundlegen dinge zur Python Webprogrammierung mal erläutern könnte. also wie genau baue ich einfach eine HTML seite wo z.B. "Hallo Welt" drin steht. Wie und Wo muss ich speichern, welche Einstellungen sind beim Apache (xampp) nötig. Muss ich was bei dem arbeiten von Linux und Win etwas beachten (zuhause Linux auf der arbeit win2k)?...

Wenn mich jemand genau das fragen würde, würde ich ihm immer:

http://www.rubyonrails.com

empfehlen. Ja Rails ist nicht Python, sondern Ruby, aber: Mit Ruby und Rails erhältst du alles, was du zum Entwickeln von Webanwendungen brauchst. Es ist einfach zu installieren (für Win gibts ein One-Click-Installer, für Linux entsprechende Packete (lang lebe apt!)) und es ist alles dabei was man braucht (ORM für Datenbank, simple Templatesprache, Klare Trennung zwischen Modell und View, Unit-Tests, ...) und insgesamt verdammt einfach zu bedienen und, das allerwichtigste, es macht Spass damit zu entwickeln. Das ist mir nach einem grösserem J2EE Projekt sowas von klar geworden... ich hab mich nach Alternativen umgeschaut, und bin auch zuerst auf Python gestoßen. Aber bei Python wars leider ähnlich wie bei J2EE. 1000 halbe Projekte, einige sehr wirre Quasistandards und insgesamt einfach unglaublich unübersichtlich... In meiner Verzweiflung hab ich weitergesucht und bin kurz darauf auf RoR gestoßen und muss sagen, ich bin wirklich beeindruckt davon.

Also an alle, die demnächst ein neues Webprojekt anfangen und denen es um effektive Entwicklung und Umsetztung geht, unbedingt mal über den Tellerrand schauen! Es lohnt sich.

[jens]

Dabei sollte man allerdings nicht außer acht lassen, das Ruby noch seltener als Python bei normalen Web-Space anzutreffen ist. s.: http://wiki.python.de/Python_Webspace

Wie läuft RoR denn? Mit CGI?

[synopia]

Dabei sollte man allerdings nicht außer acht lassen, das Ruby noch seltener als Python bei normalen Web-Space anzutreffen ist. s.: http://wiki.python.de/Python_Webspace

Wie läuft RoR denn? Mit CGI?

Absolut korrekt. Mit RoR wird man an einem eignem Server (VServer, etc) (noch) nicht vorbeikommen.

Es gibt mindestens 3 Möglichkeiten:
1. Reiner Rubywebserver (Webbricks oder so), Vorteil: Easy to use (nix konfigurieren, einfach starten), Nachteil: Langsam --> Fahrradantrieb
2. Apache mit CGI: Nachteil: Ottomotor
3. Apache mit FCGI: Raketenantrieb
4. Lighttp mit FCGI: Warpantrieb

PS: Buchempfehlung darf nicht fehlen: "Agile Webentwicklung mit Rails", Hanser Verlag
PPS: Hoster mit RoR auf FCGI

[mitsuhiko]

Es gibt mindestens 3 Möglichkeiten:
1. Reiner Rubywebserver (Webbricks oder so), Vorteil: Easy to use (nix konfigurieren, einfach starten), Nachteil: Langsam --> Fahrradantrieb
2. Apache mit CGI: Nachteil: Ottomotor
3. Apache mit FCGI: Raketenantrieb
4. Lighttp mit FCGI: Warpantrieb

Wo ist da jetzt der Unterschied zu django und turbogears? Hey und sogar für Colubrid trifft das zu.
Und ich glaube, dass TurboGears jetzt schon mächtiger als Ruby ist.

[synopia]

Hey, ich kannte bisher weder turbogears noch django. Beide gehen den RoR-Way, was ich nur gutheißen kann

Natürlich gibt es keinen Unterschied zwischen der Konfiguration von Turbogears und RoR für den Webserver, beides läuft erst richtig rund auf einem FCGI (und schnell unter lighttp), nur hatte mein Vorposter eben gefragt...

Allerdings halte ich es für ein Gerücht, dass Turbogears mächtiger ist als RoR (Ruby hat im Übrigen nix mit Rails zu tun...). Wenn ich mir die Doku ansehe, ist vieles noch nicht dokumentiert und nur für die Alphaversion verfügbar. RoR ist schon eine ganze Weile "Stable" und es gibt inzwischen ein paar sehr gute Bücher (Bisher war ich der festen Überzeugung, dass man Bücher nicht braucht, da man alles aktueller im Web nachlesen kann, nun hab ich mir aber das oben genannte zugelegt und muss sagen, es geht viel.. vieeeel schneller sich mit einem (guten) Buch in ein solches Framework einzuarbeiten).

Im Übrigen wollte ich hier niemandem zu nahe treten, ich hab lediglich versucht auf die eigentliche Frage des TE einzugehen.

Ob nun Ruby oder Python ist jedem selbst überlassen, ich merke nur noch mal an, was im Pragmatischen Programmierer steht: Lerne jedes Jahr 2 neue Programmiersprachen...

[gerold]

Wo ist da jetzt der Unterschied zu django und turbogears? Hey und sogar für Colubrid trifft das zu. Und ich glaube, dass TurboGears jetzt schon mächtiger als Ruby ist.

Alle diese Web-Frameworks inklusive Zope haben von Anfang an gleich auf die richtige Programmiersprache gesetzt. Das kan RoR nie mehr aufholen.

mfg
Gerold

[gerold]

was im Pragmatischen Programmierer steht: Lerne jedes Jahr 2 neue Programmiersprachen...

Hi synopia!

Dem kann ich nicht zustimmen. Man braucht Jahre um aus einer Programmiersprache wie Python alles raus zu holen. Es gibt viele Module die man erst nach und nach kennen lernt. Würde man jedes Jahr eine oder zwei zusätzliche Programmiersprachen lernen, würde man in allen wahrscheinlich nur mittelmäßig sein. Man ist meistens mit *der* Programmiersprache am Besten, die man ständig einsetzt.

mfg
Gerold