mod_python: multiple inheritance

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
rossco
User
Beiträge: 2
Registriert: Mittwoch 22. Februar 2006, 12:02

hallo python-gemeinde.

ich bin derzeit mit der entwicklung eines größeren online-projektes beschäftigt. dieses stützt sich zum zwecke der dynamischen seiten-erstellung auf mod_python.
das projekt ist inzwischen knapp 60 module groß und läuft rund - es ist nicht das erste mal, dass ich etwas in dieser größenordnung mittels mod_python realisiere, doch heute musste ich leider an einen punkt stoßen, an dem mich meine (mod_-)python-erfahrung nicht mehr weiter bringt.

folgende konstellation:

modul mod1.py

Code: Alles auswählen

class MyTestBase:

  def __init__(self):
    self.a = None
modul mod2.py

Code: Alles auswählen

from mod1 import MyTestBase

class MyFirstDerive(MyTestBase):

  def __init__(self):
    MyTestBase.__init__(self)


class MySecondDerive(MyFirstDerive):

  def __init__(self):
    MyFirstDerive.__init__(self)
modul mod3.py

Code: Alles auswählen

from mod2 import MySecondDerive

blub = MySecondDerive()
so weit, so gut.
wenn nun der code in mod3 ausgeführt wird, also eine instanz von MySecondDerive erzeugt wird, funktioniert vorerst alles wunderbar.
auch ein zweiter call des codes läuft einwandfrei.
doch irgendwann, meist bereits beim dritten durchlauf des codes, erhalte ich schließlich folgende exception:

Code: Alles auswählen

TypeError: unbound method __init__() must be called with MyFirstDerive instance as first argument (got MySecondDerive instance instead)
mir scheint es nicht, als ob ein fehler in meinem code vorliegt - schließlich läuft er ja ein paar mal einwandfrei.
google möchte mir in der hinsicht auch nichts wirklich hilfreiches unterbreiten, daher nun mein post in diesem forum.
man könnte meinen, es würde sich um einen bug in mod_python handeln. daher hier die versions-nummern der verwandten komponenten:

python: 2.3.5
mod_python: 3.1.3
apache: 2.0.55

schon einmal vielen dank im vorraus!

grüße aus hamburg,
simon
henning
User
Beiträge: 274
Registriert: Dienstag 26. Juli 2005, 18:37

Ich hab jetzt noch nicht genauer über dein Problem nachgedacht, würde es aber mal einfach pauschal in folgende Ecke stellen:

- Alle python-Module und instanzen deiner webanwendungen laufen bei mod_python im selben Interpreter. (Was z.B. sehr ärgerlich sein kann, wenn man verschiedene Versionen von einem Modul auf ein und demselben Webserver laufen lassen will)

- mod_python bzw. Apache bestimmen nach gut dünken, wann sie Module neu laden, sprich wann Modul-Level-Code (also alles ausserhalb von Funktionen) wirklich ausgeführt wird.

Da ich zur Zeit auch (noch) an einem größerem mod_python-Projekt arbeite habe ich die leidvolle Erfahrung gemacht, dass dieses Verhalten oftmals zu sehr unerwünschten und schwer debug- und behebbaren Problemen führen kann, da unter Umständen die lustigsten Dinge passieren.

(Ich hatte es z.B. ein mal hingekriegt, dass zwei Variablen, die auf die selbe DB-Verbindung zeigen sollten, auf einmal auf verschiedene zeigten, eine auf die tote aus dem letzen request und eine auf eine neue und das _obwohl_ sie synchronieiert wurden [aber frag mich jetzt nicht wie]).

Kurzum, ich habe im Kopf ein wenig Arbeitszeiten abgeschätzt und festgestellt, dass ich schneller das ganze Projekt in Django neu bauen kann, als die grundlegenden Probleme mit mod_python wirklich zu beheben oder adäquat zu umgehen.

Django hat gegenüber mod_python folgende Vorteile bzw. abgrenzende Eigenschaften:
- Es ist ein komplettes Webframework, das Model-View-Controller unterstützt. z.B. baut man Klassen die Django dann automatisch in SQL-Tabellen umsetzt und es gibt einen Standard-Editor für diese Tabellen (der "admin") den man auch sher gut konfigurieren und anpassen kann.

- Es ist WSGI kompatibel, d.h. der Django-Code läuft auch "on-top-of" mod_python oder als CGI, FastCGI, oder, oder, oder...

- Die MVC-Trennung strukturiert den Code um einiges besser als ich das derzeit von Hand bei meinem mod_python-Projekt gemacht habe.

- Django hat eine eigene Template-Engine, man kann aber AFAIK auch jede andere benutzen.


Wenn dir ein komplettes Framework zu viel ist, bist du evtl. auch schon gut beraten, deinen Code nach WSGI zu portieren.
Allerdings weiß ich nicht, in wie fern das solche Probleme löst.
rossco
User
Beiträge: 2
Registriert: Mittwoch 22. Februar 2006, 12:02

vor lauter verzweifelung habe ich nun auch unorthodoxe methoden angewandt. daher habe ich naiver weise einfach mal jede der oben angesprochenen klassen in eine eigene datei ausgelagert. mittels imports lässt sich die gewollte vererbungsstruktur dann ja weiterhin herstellen.

und siehe da: es läuft einwandfrei.

allerdings würde ich diese lösung eher als workaround ansehen - eine schlussendliche erklärung für das fehlverhalten auf mod_python-seite steht weiterhin aus.

greets.
henning
User
Beiträge: 274
Registriert: Dienstag 26. Juli 2005, 18:37

Wie gesagt, ich bin ziemlich sicher, dass das mit dem merkwürdigen Modul-Ladeverhalten von mod_python zu tun hat...
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

mod_python direkt solle man nicht mehr verwenden. Du machst dich davon abhängig und musst auch mit den mod_python Problemen leben.

Mach deine Anwendung einfach WSGI kompatibel und du hast das Problem nicht.
TUFKAB – the user formerly known as blackbird
Antworten