Das deutsche Python-Forum

Vielen dank für die Info...

In dem Fall, sollte ich mir das ganze auch mal ansehen

@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?

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.

Geplant ist das Egg mit allem drum und dran spätestens Ende November fertigzustellen.
Momentan weiß ich noch nicht, ob die die sourcen von flup auch wirklich in das Paket übernehmen kann, warte noch auf Antwort vom Author.

henning hat geschrieben:Mich würde btw. noch sehr interessieren inwiefern ein wsgi-wrapper für mod_python das Modul-Ladeverhalten beeinflusst.

Ich lade die WSGI Anwendung im Falle von mod_python für die htaccess.

Code: Alles auswählen

            SetHandler python-program
            PythonHandler wsgi.wrappers.modpy::handler
            PythonOption application my_application::app
        </Directory>

Die Anwendung wird vom WSGI Wrapper dann mit hilfe des apache modules geladen. Details gibts hier

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!).

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:Wenn WSGI-Anwendungen auf allen WSGI-Plattforman laufen sollen, dann müssen die Wrapper das doch berücksichtigen, oder?

Tun sie auch

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)

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 nicht.

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?

Natürlich ist sie noch da. Bei CGI wird sie halt immer neu erstellt, bei mod_python überlebt sie.
Wenn du selber wissen willst, ob sie überlebt oder nicht, musst du nur im Environ nachsehen: (environ['wsgi.run_once'])

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 ?

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?

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:Gibt es irgendwie schon ein Beispiel, wie das ganze konkret abläuft???

Im Wiki

Und eine kleine Testanwendung ist hier: http://trac.pocoo.org/browser/wsgi/trun ... dreader.py

jens 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 ?

Dafür kann ich eine Middleware oder noch besser, dekoratoren schreiben. Da lässt sich was machen. Ideen können ja abgeliefert werden

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.

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.

Dekoratoren gehen unter python2.3 auch nur ist halt die Syntax anders:

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

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.

Ja, ich möchte auch mal wieder alles für Python 2.2.1 haben

jens hat geschrieben:Ja, ich möchte auch mal wieder alles für Python 2.2.1 haben

Das wird sich nicht wirklich machen lassen. Ich verwende schon genug Features aus Python2.3

Warum zur Hölle so alte Python Versionen noch unterstützen?

blackbird hat geschrieben:
jens 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?

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 an

Ich weiß allerdings keinen anderen Provider Preis/Leistung/Zuverlässigkeit...

jens hat geschrieben:
blackbird hat geschrieben:
jens 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?
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 an

Ich weiß allerdings keinen anderen Provider Preis/Leistung/Zuverlässigkeit...

Was zahlst du? Wenn du dich mit Linux auskennst und du vor Allem python drauf laufen lassen willst: alturo.de

Ansonsten python compilieren und ins webverzeichniss hochladen.

blackbird hat geschrieben:Was zahlst du? Wenn du dich mit Linux auskennst und du vor Allem python drauf laufen lassen willst: alturo.de

z.Z. Nutze ich das WebPack M für 3€ p.M.

Welche Version hat den alturo.de beim "Webmaster"-Paket installiert? Oder nutzt du da einen Server?

blackbird hat geschrieben:Ansonsten python compilieren und ins webverzeichniss hochladen.

Hm! Das geht???

joe hat geschrieben:
henning hat geschrieben:Wenns es einen Browser gibt *gegen* den man optimieren darf, dann ist es wohl der IE ,-)
Best viewed with !IE
joe

Leider nicht. Das IE hat nunmal noch so um die 70% Marktanteil, IIRC.

jens hat geschrieben:Welche Version hat den alturo.de beim "Webmaster"-Paket installiert? Oder nutzt du da einen Server?

für pocoo.org verwende ich einen server, für meine homepage hab ich bei hosteurope ein Webpack L.

jens hat geschrieben:
blackbird hat geschrieben:Ansonsten python compilieren und ins webverzeichniss hochladen.
Hm! Das geht???

Ich wüsste nicht warum nicht.

@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 ^^

blackbird hat geschrieben:Was zahlst du? Wenn du dich mit Linux auskennst und du vor Allem python drauf laufen lassen willst: alturo.de

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...

Ich hab im Wiki eine Seite eingerichtet, um festzuhalten, wer was anbietet:
http://www.pythonwiki.de/PythonWebspace

Und wieder was Neues. Eine AJAX Middleware und eine dazu passende Beispielanwendung.

Dann machst du mit wsgi also weiter???

Das deutsche Python-Forum

WSGIarea online