Vielen dank für die Info...
In dem Fall, sollte ich mir das ganze auch mal ansehen
WSGIarea online
@blackbird: Kannst du schon ne Prognose abgeben, wann dieses egg fertig sein wird? Hätte nämlich eh größere arbeiten anstehen dann könnte ich in dem Zug auch auf WSGI umstellen.
Mich würde btw. noch sehr interessieren inwiefern ein wsgi-wrapper für mod_python das Modul-Ladeverhalten beeinflusst.
Bei CGI wird ja glaub ich alles immer neu geladen. Bei mod_python ist das nicht grundsätzlich der Fall, da hängt die Lebensdauer ja von den Apache-Threads etc... ab (u.U. werden sie dogar erst beim apache-neustart neu geladen!).
Wenn WSGI-Anwendungen auf allen WSGI-Plattforman laufen sollen, dann müssen die Wrapper das doch berücksichtigen, oder?
Mich würde btw. noch sehr interessieren inwiefern ein wsgi-wrapper für mod_python das Modul-Ladeverhalten beeinflusst.
Bei CGI wird ja glaub ich alles immer neu geladen. Bei mod_python ist das nicht grundsätzlich der Fall, da hängt die Lebensdauer ja von den Apache-Threads etc... ab (u.U. werden sie dogar erst beim apache-neustart neu geladen!).
Wenn WSGI-Anwendungen auf allen WSGI-Plattforman laufen sollen, dann müssen die Wrapper das doch berücksichtigen, oder?
-
- User
- Beiträge: 1790
- Registriert: Donnerstag 28. Oktober 2004, 16:33
- Wohnort: Graz, Steiermark - Österreich
- Kontaktdaten:
Geplant ist das Egg mit allem drum und dran spätestens Ende November fertigzustellen.henning hat geschrieben:@blackbird: Kannst du schon ne Prognose abgeben, wann dieses egg fertig sein wird? Hätte nämlich eh größere arbeiten anstehen dann könnte ich in dem Zug auch auf WSGI umstellen.
Momentan weiß ich noch nicht, ob die die sourcen von flup auch wirklich in das Paket übernehmen kann, warte noch auf Antwort vom Author.
Ich lade die WSGI Anwendung im Falle von mod_python für die htaccess.henning hat geschrieben:Mich würde btw. noch sehr interessieren inwiefern ein wsgi-wrapper für mod_python das Modul-Ladeverhalten beeinflusst.
Code: Alles auswählen
SetHandler python-program
PythonHandler wsgi.wrappers.modpy::handler
PythonOption application my_application::app
</Directory>
Jup. Ein mod_python Thread lebt ewig, daher auch sehr schnell. Zu Enwicklungszwecken würde ich deswegen immer mit einem CGI Wrapper arbeiten und mod_python erst im Produktivsystem einsetzten.henning hat geschrieben:Bei CGI wird ja glaub ich alles immer neu geladen. Bei mod_python ist das nicht grundsätzlich der Fall, da hängt die Lebensdauer ja von den Apache-Threads etc... ab (u.U. werden sie dogar erst beim apache-neustart neu geladen!).
Tun sie auchhenning hat geschrieben:Wenn WSGI-Anwendungen auf allen WSGI-Plattforman laufen sollen, dann müssen die Wrapper das doch berücksichtigen, oder?
TUFKAB – the user formerly known as blackbird
Sorry, ich habe immer noch nicht vertanden, wie das jetzt ist.
Untergräbt der WSGI-Wrapper jetzt nun diese Eigenschaft von mod_python oder nicht?
Ganz banal gefragt:
Wenn ich bei einem request eine Modulglobale Variable setze, ist sie dann beim nächsten Request noch da oder nicht?
Bei mod_python war sies ja (zumindest wenn der apache-thread so lange gelebt hat). Bei CGI wäre sie's grundsätzlich nicht. Oder hast du versucht mir zu sagen, dass man seinen Code halt für beide Fälle schreiben muss? (Im Grunde kann ich mich ja auch in mod_python nicht drauf verlassen, dass zu einem bestimmten Zeitpunkt der Thread noch lebt und muss ggf. davon ausgehen, dass alles neu geladen worden ist)
Untergräbt der WSGI-Wrapper jetzt nun diese Eigenschaft von mod_python oder nicht?
Ganz banal gefragt:
Wenn ich bei einem request eine Modulglobale Variable setze, ist sie dann beim nächsten Request noch da oder nicht?
Bei mod_python war sies ja (zumindest wenn der apache-thread so lange gelebt hat). Bei CGI wäre sie's grundsätzlich nicht. Oder hast du versucht mir zu sagen, dass man seinen Code halt für beide Fälle schreiben muss? (Im Grunde kann ich mich ja auch in mod_python nicht drauf verlassen, dass zu einem bestimmten Zeitpunkt der Thread noch lebt und muss ggf. davon ausgehen, dass alles neu geladen worden ist)
-
- User
- Beiträge: 1790
- Registriert: Donnerstag 28. Oktober 2004, 16:33
- Wohnort: Graz, Steiermark - Österreich
- Kontaktdaten:
Natürlich nicht.henning hat geschrieben:Sorry, ich habe immer noch nicht vertanden, wie das jetzt ist.
Untergräbt der WSGI-Wrapper jetzt nun diese Eigenschaft von mod_python oder nicht?
Natürlich ist sie noch da. Bei CGI wird sie halt immer neu erstellt, bei mod_python überlebt sie.henning hat geschrieben:Ganz banal gefragt:
Wenn ich bei einem request eine Modulglobale Variable setze, ist sie dann beim nächsten Request noch da oder nicht?
Wenn du selber wissen willst, ob sie überlebt oder nicht, musst du nur im Environ nachsehen: (environ['wsgi.run_once'])
TUFKAB – the user formerly known as blackbird
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Das überleben von Variablen passiert bei mir im Session-Handling... So wie ich das jetzt verstehe, sollte es doch eigentlich mit WSGI auf die gleiche Art erfolgen, das heißt als CGI und mod_python auf die selbe Art. Sodas ein Programm mit beiden, ohne Anpassung läuft, oder?
Gibt es irgendwie schon ein Beispiel, wie das ganze konkret abläuft???
EDIT: Ach, was ist eigentlich mit der Problematik mit dem Parameter-Übergabe an Methoden??? Gibt es da irgendwas in Verbindung mit WSGI oder den middlewares ?
Gibt es irgendwie schon ein Beispiel, wie das ganze konkret abläuft???
EDIT: Ach, was ist eigentlich mit der Problematik mit dem Parameter-Übergabe an Methoden??? Gibt es da irgendwas in Verbindung mit WSGI oder den middlewares ?
-
- User
- Beiträge: 1790
- Registriert: Donnerstag 28. Oktober 2004, 16:33
- Wohnort: Graz, Steiermark - Österreich
- Kontaktdaten:
So eine Anwendung schaut nicht wie CGI aus, kann sie technisch nicht, da CGI ja nicht von überlebenden und temporären Variablen unterscheiden kann. Der CGI Wrapper kennt nur temporäre, thread übergreifende werden trotzdem jedesmal neu erstellt.jens hat geschrieben:Das überleben von Variablen passiert bei mir im Session-Handling... So wie ich das jetzt verstehe, sollte es doch eigentlich mit WSGI auf die gleiche Art erfolgen, das heißt als CGI und mod_python auf die selbe Art. Sodas ein Programm mit beiden, ohne Anpassung läuft, oder?
Im Wikijens hat geschrieben:Gibt es irgendwie schon ein Beispiel, wie das ganze konkret abläuft???
Und eine kleine Testanwendung ist hier: http://trac.pocoo.org/browser/wsgi/trun ... dreader.py
Dafür kann ich eine Middleware oder noch besser, dekoratoren schreiben. Da lässt sich was machen. Ideen können ja abgeliefert werdenjens hat geschrieben:EDIT: Ach, was ist eigentlich mit der Problematik mit dem Parameter-Übergabe an Methoden??? Gibt es da irgendwas in Verbindung mit WSGI oder den middlewares ?
TUFKAB – the user formerly known as blackbird
-
- User
- Beiträge: 1790
- Registriert: Donnerstag 28. Oktober 2004, 16:33
- Wohnort: Graz, Steiermark - Österreich
- Kontaktdaten:
Dekoratoren gehen unter python2.3 auch nur ist halt die Syntax anders:henning hat geschrieben:Bitte keine Dekoratoren, das aktuelle Debian mod_python ist mit 2.3 kompiliert, die könnte ich dann nicht nutzen ohne mir mein mod_python neu zu kompilen.
Code: Alles auswählen
def mein_deco(f):
def wrapped(f, *args, **kwargs):
return f(*args, **kwargs) + ' blub'
return wrapped
#python2.3:
def function(spam):
return 'blub %s' % spam
function = mein_deco(function)
#python 2.4
@mein_deco
def function(spam):
return 'blub %s' % spam
TUFKAB – the user formerly known as blackbird
Ja eben und das ist gerade bei längeren Funktionen SEHR unschön, weil man solche Sachen doch lieber in der Nähe des Funktionskopfes hat, siehe den Thread auf den jens schon hingewiesen hat, da haben wir schon einige Alternativen diskutiert.
-
- User
- Beiträge: 1790
- Registriert: Donnerstag 28. Oktober 2004, 16:33
- Wohnort: Graz, Steiermark - Österreich
- Kontaktdaten:
Das wird sich nicht wirklich machen lassen. Ich verwende schon genug Features aus Python2.3jens hat geschrieben:Ja, ich möchte auch mal wieder alles für Python 2.2.1 haben
Warum zur Hölle so alte Python Versionen noch unterstützen?
TUFKAB – the user formerly known as blackbird
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Frag nicht mich, frag Hosteurope Ich verstehe es auch nicht, warum die nicht mal in die Schuh kommen... Bei PHP bieten die natürlich was brand aktuelles anblackbird hat geschrieben:Warum zur Hölle so alte Python Versionen noch unterstützen?jens hat geschrieben:Ja, ich möchte auch mal wieder alles für Python 2.2.1 haben
Ich weiß allerdings keinen anderen Provider Preis/Leistung/Zuverlässigkeit...
-
- User
- Beiträge: 1790
- Registriert: Donnerstag 28. Oktober 2004, 16:33
- Wohnort: Graz, Steiermark - Österreich
- Kontaktdaten:
Was zahlst du? Wenn du dich mit Linux auskennst und du vor Allem python drauf laufen lassen willst: alturo.dejens hat geschrieben:Frag nicht mich, frag Hosteurope Ich verstehe es auch nicht, warum die nicht mal in die Schuh kommen... Bei PHP bieten die natürlich was brand aktuelles anblackbird hat geschrieben:Warum zur Hölle so alte Python Versionen noch unterstützen?jens hat geschrieben:Ja, ich möchte auch mal wieder alles für Python 2.2.1 haben
Ich weiß allerdings keinen anderen Provider Preis/Leistung/Zuverlässigkeit...
Ansonsten python compilieren und ins webverzeichniss hochladen.
TUFKAB – the user formerly known as blackbird
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
z.Z. Nutze ich das WebPack M für 3€ p.M.blackbird hat geschrieben:Was zahlst du? Wenn du dich mit Linux auskennst und du vor Allem python drauf laufen lassen willst: alturo.de
Welche Version hat den alturo.de beim "Webmaster"-Paket installiert? Oder nutzt du da einen Server?
Hm! Das geht???blackbird hat geschrieben:Ansonsten python compilieren und ins webverzeichniss hochladen.
Leider nicht. Das IE hat nunmal noch so um die 70% Marktanteil, IIRC.joe hat geschrieben:Best viewed with !IEhenning hat geschrieben:Wenns es einen Browser gibt *gegen* den man optimieren darf, dann ist es wohl der IE ,-)
joe
-
- User
- Beiträge: 1790
- Registriert: Donnerstag 28. Oktober 2004, 16:33
- Wohnort: Graz, Steiermark - Österreich
- Kontaktdaten:
für pocoo.org verwende ich einen server, für meine homepage hab ich bei hosteurope ein Webpack L.jens hat geschrieben:Welche Version hat den alturo.de beim "Webmaster"-Paket installiert? Oder nutzt du da einen Server?
Ich wüsste nicht warum nicht.jens hat geschrieben:Hm! Das geht???blackbird hat geschrieben:Ansonsten python compilieren und ins webverzeichniss hochladen.
@Joghurt: Du kannst das Design ja in den Benutzeroptionen auf modern umstellen. das funzt auch mit IE
----
In der Zwischenzeit gibts einige neue Middleware Systeme.
Google Highlighter, Chrome (für statischen Inhalt) inkl thumbnailer ^^
TUFKAB – the user formerly known as blackbird
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Hab mal bei denen Nachgefragt. Bei dem normalen "Webmaster"-Webspace Paket ist das uralte Python v2.1 installiert, allerdings ist mod_Python und fast_cgi wohl verfügbar...blackbird hat geschrieben:Was zahlst du? Wenn du dich mit Linux auskennst und du vor Allem python drauf laufen lassen willst: alturo.de
Ich hab im Wiki eine Seite eingerichtet, um festzuhalten, wer was anbietet:
http://www.pythonwiki.de/PythonWebspace
-
- User
- Beiträge: 1790
- Registriert: Donnerstag 28. Oktober 2004, 16:33
- Wohnort: Graz, Steiermark - Österreich
- Kontaktdaten:
Und wieder was Neues. Eine AJAX Middleware und eine dazu passende Beispielanwendung.
TUFKAB – the user formerly known as blackbird