Machbarkeitsanfrage Python oder andere Sprache

[sma]

Aber selbst bei 1000 kann die Datenmenge zwischen 1-4 MB liegen, unoptimiert natürlich.

Ich vermute, 4 MB für 1000 Clients, also 4 KB pro Client. Das ist doch prinzipiell möglich, dein Server muss dafür aber mit mehr als 40 MBit angeschlossen sein. Allerdings pustest du so pro Stunde 14 GB ins Netz, oder 10 TB pro Monat. Oh, ich sehe gerade, du willst das auch noch X-mal pro Sekunden schaffen, mehr als 2 ist bei typischen Mietservern wahrscheinlich nicht drinn.

Das habe ich prinzipiell verstanden, aber ist denn sowas in Python möglich? Habe da gerade von Stackless Python gelesen, wäre das was?

Ich bin da kein Experte, aber ich denke, nein, es ist nicht möglich. Stackless kann zwar mit tasklets fast beliebig viele Threads oder Prozesse simulieren, dennoch ist das immer nur ein Betriebssystem-Prozess (und wohlmöglich auch nur ein Thread, da weiß ich's nicht) und das skaliert überhaupt nicht.

Sind denn 2GB bei Servern nicht schon beinahe normal?

Sie nur für die Systemstacks der Betriebssystemthreads zu benötigen würde ich dennoch als grobe Verschwendung bezeichnen.

Ich möchte es halt so konzipieren, dass, wenn es denn Leuten gefällt, ich einfach aufstocken kann. Also ein System, welches erst einmal nur maximal 250 Leuts halten kann und dann komplett neu aufgesetzt werden müsste, wäre für meine Belange nicht tauglich.

Java deutlich besser kennend als Python würde ich hier vom Bauch zu Java tendieren. Möglicherweise ist Jython ein guter Kompromiss. Leider ist dieser Python-Dialekt immer noch veraltet. Doch zumindest wurde das Projekt vor einiger Zeit ja wieder aus einem todesähnlichen Schlaf wachgeküsst.

Wie verhält es sich eigentlich mit IronPython? Microsofts .NET VM ist ähnlich effizient wie Sun Java-VM (wenn auch nicht ganz so gut IMHO, da sie mehr in Richtung Client als für Serverbelange optimiert ist) und dort könnte man den performance-kritischen Teil in C# schreiben und direkt mit IronPython kombinieren.

Ich würde zwar lieber Java als offenere Plattform empfehlen, aber IronPython scheint mir deutlich vollständiger zu sein und wenn ich Windows als Plattform nicht stört...

Stefan

[gerold]

Hallo!

Python ist ideal um das komplette Gerüst der Anwendung zu programmieren. Nachdem man eine funktionierende Anwendung mit Python geschrieben hat, geht man daran, diese gezielt zu testen und die evt. auftretenden Performance-Engpässe zu optimieren.

Als ersten Schritt optimiert man die Algorithmen, die sich als Engpass erweisen -- falls es so etwas überhaupt gibt.

Dann bindet man Psyco http://psyco.sourceforge.net/ mit ein. Das kann bei Berechnungen und Stringoperationen Wunder wirken.

Wenn das immer noch nicht so viel bringt wie man es gerne haben möchte, dann lagert man die performancekritischen Algorithmen aus.

Dafür gibt es pyrex http://www.cosc.canterbury.ac.nz/greg.e ... hon/Pyrex/ oder Cython http://www.cython.org/.

Der Vorteil dieser Vorgehensweise liegt auf der Hand. Man sieht sehr schnell Fortschritte. Funktionierende Programme sind sehr schnell erstellt. Oft braucht man nichts oder nur sehr wenig zu optimieren und spart sich dadurch extrem viel Zeit, die ansonsten durch unkontrolliertes Voraboptimieren drauf gehen würde.

Die nächste wichtige Sache ist der Datenspeicher.

Wenn man die Datenspeicherung einem Datenbanksystem wie z.B. PostgreSQL überlässt, dann kann man dieses Datenbanksystem auf einen eigenen Computer mit schnellen Gigabit-Netzwerkverbindungen auslagern. So kann ein schneller Datenbankserver mit viel RAM mehrere Auslieferserver (Proxy) bedienen. In weiterer Folge kann man die Last sogar auf mehrere Datenbankserver mit gespiegelten Daten aufteilen. Man kann Schreiboperationen an einen eigenen Datenbankserver übermitteln. Dieser kümmert sich dann darum, dass die neuen Daten sofort an die anderen Datenbankserver weitergegeben werden. Oft ist es so, dass ein Großteil der ganz neuen Daten für die Clients nicht wichtig ist. Deshalb kann das sogar verzögert stattfinden. Man kann auch mehrere Datenbankserver im Multimaster-Betrieb zusammenschließen. Das hat den Vorteil, dass der Client, der die neuen Daten übermittelt hat, sofort damit arbeiten kann. Alle Clients, die mit dem selben Datenbankserver arbeiten, haben diese Daten auch sofort zur Verfügung. Nur die Clients, die mit einem anderen Datenbankserver verbunden sind, bekommen die neuen Daten verzögert mit.

Solche Strategien gibt es viele und müssen teilweise schon während dem Programmieren berücksichtigt werden. Z.B. kann man keine fortlaufende Zahl als Index verwenden. Dafür verwendet man stattdessen GUIDs (Global Unique IDs). So fällt ein Probleme beim Synchronisieren weg.

Also ich würde einfach mal mit einem Server anfangen und damit alles so programmieren, dass man damit die ersten paar hundert Clients gut bedienen kann. Es hat sich noch *nie* rentiert, schon vorab zu optimieren. Und davon kann ich ein Lied singen. Ich war auch mal so ein Voraboptimierer.

Man muss immer eines Bedenken:
- 1.) Meistens kommt es anders!
- 2.) Als man denkt!"

Was den Server betrifft, kann ich dir nur zu Hetzner http://hetzner.de/ raten. Die vermieten für wenig Geld wirklich leistungsstarke Server und gute Netzanbindung. Das Service ist nicht schlecht und Emails werden persönlich und nicht von einem Computer beantwortet.

Weiters würde ich dir dazu raten, das Buch "Exploring Python" zu lesen. -- Aber erst dann, wenn du vorher ein paar andere Python-Bücher gelesen hast. -- Dort erfährst du etwas über Koroutinen und Continuations, Generatoren, Microthreads, usw. Damit weißt du dann genug darüber um entscheiden zu können, ob sie dir für dein Vorhaben etwas bringen oder nicht.

Du kannst außerdem Aufgaben auf mehrere einzelne Programme aufteilen. Da diese die gleiche Datenbasis, also die Datenbank, benutzen können, brauchst du dir dadurch keine Sorgen über die Auslastung des Systems machen. Mehrere Prozesse müssen ja nicht immer nur von einem einzigen Programm ausgehen. Man kann mehrere Programme parallel laufen lassen und diesen Programmen Nachrichten übermitteln.

Und wir sind hier ein Python-Board. Kein "nimm lieber Java, weil ich kenn mich in Java besser aus"-Board. Python ist das Zauberbuch und wir sind die Zauberer. Manche finden das früher und manche später heraus.

mfg
Gerold

[Yogi]

Ich vermute, 4 MB für 1000 Clients, also 4 KB pro Client. Das ist doch prinzipiell möglich, dein Server muss dafür aber mit mehr als 40 MBit angeschlossen sein. Allerdings pustest du so pro Stunde 14 GB ins Netz, oder 10 TB pro Monat. Oh, ich sehe gerade, du willst das auch noch X-mal pro Sekunden schaffen, mehr als 2 ist bei typischen Mietservern wahrscheinlich nicht drinn.

Deswegen ja auch die Beschränkung auf die meinetwegen 20 umliegenden Planeten. Also worst-case alle 1000 Clients online:

1000 Clients * 4Bytes * 20 Planeten = ca. 194 GB pro Monat bei sekündlicher Berechnung. Aber du hast ja recht, bei einer Million Clients und 20 Planeten jeweils zu übertragen werdens schwindelerregende 189 TB <Schluck>
Aber Gott sei Dank ist das noch fernste Zukunftsmusik und es sind ja nie alle Clients online!

Aber wenn mein Projekt was werden sollte, dann wird das irgend wann tum Problem werden. Hoffentlich sind bis dahin die Server günstiger

Von IronPython halte ich momentan eher nichts. Da kann ich doch direkt C# oder Mono nehmen. Klar wäre wahrscheinlich Java besser, aber wie gehört habe, brauche Java recht performante Server (vor allem in Verbindung mit Project Darkstar).

Ich stelle es mir momentan so vor, den Server in Python zu erstellen und dann die hungrigen Teile zu optimieren und dann mal sehen. Vielleicht hat ja irgendwann ein Nicht-Egomane Lust an dem Projekt mit zu arbeiten, wenns erst mal online ist??

[Y0Gi]

"Das skaliert so nicht!(tm)"

Wenn du so eine Datenmenge rumschieben willst, dann dann ist HTTP definitiv eine schlechte Wahl. Und wenn es auch noch Realtime-nah sein soll, kommst du an UDP kaum vorbei: Mölglichst wenig Overhead und verspätet eintreffende oder fehlende Pakete werden verworfen. Das wird dann zwar im Webbrowser schwierig, aber der ist dann auch nicht mehr die richtige Plattform für so einen Client.

Beim weiteren Lesen habe ich auch direkt daran gedacht, die Berechnungen auf dem Client ausführen zu lassen, gerade wenn die Umlaufbahnen voraussehbar sind. Bei einer Simulation ist das allemal egal, bei einem Spiel sollte man dagegen Manipulationen erkennen können, etwa wenn (mal als Beispiel) die Kollision des Raumschiffs des Anwenders mit einem Planeten Nachteile bringt, die man durch Fehlangabem vom Client vermeiden könnte.

Von .NET/C# und was da zugehört halte ich persönlich relativ wenig. Wenn ich mich damit auseinandersetzen wollte, würde ich mir aber wohl zunächst Konsorten wie Boo ansehen.

Python ist das Zauberbuch und wir sind die Zauberer.

gerold, meinen Respekt für diesen erstklassigen Spruch. *Den* noch mit einer Simon-the-Sorcerer-ähnlichen Illustration versehen und das gäbe ein absolut hammermäßiges T-Shirt ...

[Yogi]

@gerold: Das hat mich jetzt sehr weiter gebracht. Danke! Interessant auch, deine Optimierungsreihenfolge. Ich hatte gedacht, direkt mit pyrex zu optimieren, ohne psyco Zwischenschritt.

Wegen der DB, ist das denn keine Bremse, wenn ich andauernd die Daten von der DB hole? Da müsste noch ein Caching her.
Sehr interessant die Aussage, dass man zwischen parallel arbeitenden Programmen Nachrichten übermittlen kann.

@YOGi, oh mist, ich hatte zu spät die relativ gleiche Namensgebung gesehen. Nun ja, musst jetzt damit leben, eine Verwechslung ist ja ausgeschlossen

Ich glaube, irgend wo über einen UDP Modul für Flash gelesen zu haben, ansonsten müsste doch erst einmal TCP dran glauben... Am Anfang dürfte das aber kein Problem sein.

Leider kann ich die Berechnungen nicht auf den Clients durchführen lassen. Der Trick ist ja, dass auch wenn die Clients nicht online sind, die Planeten weiter agieren/reagieren. Und vorhersehbar ist leider gar nichts, da sich die Planetenkonstellationen stetig verändern können.

Edit: Was ich vergessen habe zu fragen: Stackless Ja/Nein?

[HWK]

Wenn Dich Englisch nicht schreckt, könnte Dir vielleicht Game Programming with Python eine Hilfe sein. Hier werden viele grundlegende Dinge der Spieleprogrammierung mit Python abgehandelt, u.a. auch Online-Spiele. Es ist zwar nicht ganz billig, bei caiman_amerika aber neu zum halben Preis (28,38 €) erhältlich.
MfG
HWK

[Y0Gi]

Oh, das Werk habe ich hier sogar liegen. Mal für ~15 € bei Amazon zShops geschossen. Dauert 'n paar Wochen, bis es aus Amerika/Australien/whatever da ist, aber man spartsehr viel Geld.

[Yogi]

Von Oktober 2003, ist das noch aktuell genug? War damals nicht Python 2.1 oder sowas? Vielleicht bräuchte ich ja mehr so ein generelles Netzwerk Grundlagenwerk?? Gibt ja noch ein neueres Werk... Beginning Game Development with Python and Pygame: From Novice to Professional (Expert's Voice)

[HWK]

...Vielleicht bräuchte ich ja mehr so ein generelles Netzwerk Grundlagenwerk??...

Das hier fand ich ganz toll: Foundations of Python Network Programming
MfG
HWK

[Leonidas]

...Vielleicht bräuchte ich ja mehr so ein generelles Netzwerk Grundlagenwerk??...

Das hier fand ich ganz toll: Foundations of Python Network Programming

Ohne das Buch gelesen zu haben würde ich sagen, dass ein Buch zu TCP/IP an sich schon sehr brauchbar sein kann, da Pythons ``socket``-Modul BSD-sockets nachempfunden ist und somit viele Dinge übertragbar sind. Natürlich, es gibt noch Asyncore/Medusa und Twisted, aber so viel tut sich in der Richtung nicht.

[Yogi]

Jo! das klingt wirklich gut. Das gehört wohl unter mein Kopfkissen...

[gerold]

Man kann auch mehrere Datenbankserver im Multimaster-Betrieb zusammenschließen.

Z.B. damit:

http://bucardo.org/

lg
Gerold

[Yogi]

Hi, ich dachte ich mache keinen neuen Thread auf, sondern ergänze den bestehenden.

Also, ich bin in meinem Ski-Urlaub fleissig gewesen und habe den Prototypen fertig gestellt. Es ist gut zu wissen, dass meine Idee nicht nur spinnert ist, sondern auch tatsächlich funktioniert, auch wenn ich für die visuelle Darstellung für 1000 Clients überdenken muss, da ist dann einfach zu viel los auf dem Screen. Aber das ist ganz gut, dann kann ich mit einem vernünftigen LOD, Ausblendung weiter entfernter oder nicht im Sichtfeld befindlicher Clients auch die Datenmenge schön reduzieren.

Aber jetzt wird echt happig, ich möchte jetzt alles Client-Server mässig in Python umsetzen. Und obwohl ich schon reichlich gelesen habe über Frameworks etc., bin ich kein bisschen schlauer. Immer, wenn ich denke ich habe eine Kombi, dann gibt es Stimmen, die sagen, neeee, bloss das nicht, nimm lieber das und das.... ich blick da nicht mehr durch.

Aus Kostengründen möchte ich gern erst einmal ein Server-System zu Hause aufsetzen, bevor ich einen dedicated miete.

Da wäre also erst einmal die OS Frage zu klären. Ich halte Debian 4 für eine gute Wahl, muss mich da aber erst einmal einlesen. Am liebste würde ich gerne während der anfänglichen Entwicklung unter Windows bleiben, sofern das möglich ist.

Als Datenbank MySQL.

Als Server dachte ich an CherryPy, weil das anfangs einfacher einzurichten sein soll und weil ich später Apache vorschalten kann.

Bei Apache habe ich Sorge vor den Konfiguration und den Sicherheitslücken.

Als ORM für die Datenbank dachte ich an SQLAlchemy oder Storm.

Als Templating System dachte ich an Mako oder sogar Cheetah. Da ich anfänglich die Auswertung browserbasiert haben möchte, kann ich mit XML Systemen wie Genshi nichts anfangen.

Tja und was die UDP und TCP betrifft dachte ich erst an Twisted, aber ich habe schon mehrfach lesen müssen, dass das eine ziemlich steile Lernkurve besitzt. Was gibt es noch als Alternative?


Bei allen Paketen sollte gelten, einfach in der Anwendung aber belastbar und bewährt.

Eine weitere Frage ist auch, ist es sinnvoll zwei Server zu benutzen? Der eine für das User-Management etc. und der andere für die Berechnungen und die Übermittlung der Daten für die visuelle Darstellung an die Clients.
Dann könnte ich einen normalen, gewarteten Server nehmen und einen dedicated als zweiten, der dadurch sicherer ist, dass keine Clients darauf zugreifen. Geht das überhaupt? Client sendet und empfängt von Server 1, aber empfängt nur von Server 2. Die Daten von Server2 nach Server1 und dann zum Client dürfte wohl zu lange dauern, oder?

Was meint ihr dazu?

[Leonidas]

Da wäre also erst einmal die OS Frage zu klären. Ich halte Debian 4 für eine gute Wahl, muss mich da aber erst einmal einlesen. Am liebste würde ich gerne während der anfänglichen Entwicklung unter Windows bleiben, sofern das möglich ist.

Jo, aber dann darfst du auch keine besondere Performance erwarten.

Als Datenbank MySQL.

Postgres. Spätestens wenn du Tabellen bearbeitest, deine Datenbank replizieren willst etc. wirst du bereuen es nicht zu verwenden.

Als Server dachte ich an CherryPy, weil das anfangs einfacher einzurichten sein soll und weil ich später Apache vorschalten kann.

Und allen bereichten nach skaliert es nicht. Nimm etwas anderes.

Bei Apache habe ich Sorge vor den Konfiguration und den Sicherheitslücken.

So schwer ist Apache nicht einzurichten (verglichen etwa mit der ätzenden Konfiguration von Lighty) und auf Debian gibt es Sicherheitsupdates dafür. Die letzte korrigierte Sicherheitslücke in Apache 2 war laut Security Archiv im August 2006, also sogar vor dem Release von Etch.

Als ORM für die Datenbank dachte ich an SQLAlchemy oder Storm.

Würde wohl zu SQLAlchemy raten. Es ist sicherlich komplizierter, aber kann auf lange sicht gesehen mehr (u.a. Sharding).

Als Templating System dachte ich an Mako oder sogar Cheetah. Da ich anfänglich die Auswertung browserbasiert haben möchte, kann ich mit XML Systemen wie Genshi nichts anfangen.

Mako, das ist schneller und recht gut betreut, vom gleichen Autor wie SQLAlchemy. Ich sehe allerdings dein Problem mit Genshi nicht, an welche Stelle stört dich XML?

Tja und was die UDP und TCP betrifft dachte ich erst an Twisted, aber ich habe schon mehrfach lesen müssen, dass das eine ziemlich steile Lernkurve besitzt. Was gibt es noch als Alternative?

asynchat/asyncore, Medusa, Allegra, Kamaelia.

Bei allen Paketen sollte gelten, einfach in der Anwendung aber belastbar und bewährt.

Manchmal muss man eben Kompromisse eingehen.

Die Daten von Server2 nach Server1 und dann zum Client dürfte wohl zu lange dauern, oder?

Schätze das hängt von der Netzwerkanbindung zwischen den Servern ab.

[BlackJack]

@Yogi: Zu dem "jeder sagt was anderes" würde ich sagen: Fang erst einmal an und geh' davon aus, dass Du eh eine Menge 2 bis 3mal neu schreiben wirst, wenn das alles noch komplettes Neuland für Dich ist.

Du könntest zum Beispiel erst einmal auf CherryPy aufsetzen und das Wissen, dass Du den Server später vielleicht noch einmal wechseln wirst, dazu nutzen die Logik sauber vom Rest zu trennen.

[Yogi]

@Leonidas:

Jo, aber dann darfst du auch keine besondere Performance erwarten.

Wie meinst du das?

Postgres

Ok, werde ich checken.

Bei CherryP habe ich aber den Anfangsvorteil eines schell aufgesetzten Servers und dass ich von da aus immer noch Apache mit ins Boot nehmen kann.

Aber vielleicht nimm ich erst einmal ein WAMP für den Anfang und taste mich langsam vor....?

Würde wohl zu SQLAlchemy raten.

Dann ziehe ich mir mal die Doku rein, wenn ich keine Zugang dazu finde, teste ich mal Storm.

Ich sehe allerdings dein Problem mit Genshi nicht, an welche Stelle stört dich XML

Ich denke, dass es in meinem Fall besser ist Python Code direkt eingebaut zu haben, da ich so eher so eine Art Browsergame realisieren kann, aber vielleicht irre ich mich da auch.

asynchat/asyncore, Medusa, Allegra, Kamaelia.

Checke ich mal durch, gibts da eine besondere Empfehlung?

@BlackJack:
Gerade der Anfang ist ja das schwerste. Ich kann mich vor lauter Angeboten nicht entscheiden und natürlich möchte ich nicht komplett meine Entscheidungen mitten während der Testphase revidieren müssen.
Wenn erst einmal mehrere Leute das System nutzen und ich muss dann alles neu machen bzw. eine längere Auszeit einläuten ist das nicht so optimal.

Ich möchte, glaube ich vor allem keine Sackgassen-Lösung, wenn das überhaupt machbar ist....??

[gerold]

Hallo Yogi!

Am liebste würde ich gerne während der anfänglichen Entwicklung unter Windows bleiben, sofern das möglich ist.

Jo, aber dann darfst du auch keine besondere Performance erwarten.

Du wirst während der Entwicklung keinen Unterschied merken.

Als Datenbank MySQL.

Postgres.

Postgres!

Als Server dachte ich an CherryPy

Und allen bereichten nach skaliert es nicht. Nimm etwas anderes.

CherryPy ist sauschnell, nimmt dir viel Arbeit ab und in Verbindung mit dem Apachen ein absoluter Sprinter. Du wirst nichts besseres finden was so einfach zu verwenden ist.

ORM für die Datenbank

ORMs sind eine zusätzliche Schicht zwischen der Datenbank und deinem Programm. Das ist für einfache Programme vielleicht ein Vorteil für Leute, die mit SQL nichts anfangen können.
Das kostet aber auch Rechenleistung und erschwert dir, die volle Performance aus dem Datenbankmanagementsystem raus zu kitzeln. Bei deiner Anwendung empfehle ich dir recht viel (Prozeduren, Trigger, Funktionen,...) direkt auf dem Datenbankserver PostgreSQL zu erledigen.

Die Daten von Server2 nach Server1 und dann zum Client dürfte wohl zu lange dauern, oder?

Daten übertragen dauert immer seine Zeit. Aber auch das Raussuchen der Daten aus der Datenbank. Noch dazu greift der Computer dafür auf die Festplatten zu. Und Prozessorleistung wird auch verbraten. All das kannst du damit auslagern und die Rechenzeit in der Zwischenzeit für andere Anfragen verwenden. Und sobald die Daten vom Datenbankserver angekommen sind, schickst du sie zum Client.

mfg
Gerold

[gerold]

Hallo Yogi!

Ich denke, dass es in meinem Fall besser ist Python Code direkt eingebaut zu haben, da ich so eher so eine Art Browsergame realisieren kann
[...]
Ich möchte, glaube ich vor allem keine Sackgassen-Lösung

Und genau damit würdest du in eine Sackgasse fahren.

Trenne die Darstellung vom Programm!!!

Nimm auf jeden Fall eine Vorlagensprache. Welche, ist ziemlich egal. Hauptsache ist, dass du so gut wie keine Logik in die Darstellung verlagerst. So etwas **galt** vor einigen Jahren mit "Active Server Pages" noch als schick. Inzwischen hat man größtenteils eingesehen (sogar PHP-Entwickler haben sich weiterentwickelt), dass sich solche Programme sehr schwer erweitern/verbessern lassen. Von meinen ASP-Programmen existiert kein einziges mehr.

Bei deiner Anwendung empfehle ich dir recht viel (Prozeduren, Trigger, Funktionen,...) direkt auf dem Datenbankserver PostgreSQL zu erledigen.

Ich verwende unter Windows den SQL-Manager um PostgreSQL-Datenbanken zu entwickeln.

http://sqlmanager.net/products/postgresql/manager/

Die kostenlose LITE-Version kann zwar nicht so viel wie die Vollversion -- aber immer noch besser als nur mit PgAdmin arbeiten zu müssen.

mfg
Gerold

[Y0Gi]

Bei CherryP habe ich aber den Anfangsvorteil eines schell aufgesetzten Servers und dass ich von da aus immer noch Apache mit ins Boot nehmen kann.

Ein Apache/Lighty/nginx/* wird ohnehin nur interessant, um der Python-Applikation selbst das Ausliefern von statischen Daten (Bilder, Videos usw.) abzunehmen, da Erstere darin entsprechend schnell sind.

Aber vielleicht nimm ich erst einmal ein WAMP für den Anfang und taste mich langsam vor....?

Ein einfacher Python-HTTP-Server (wsgilib, Paste, CherryPy, ...) reicht für den Anfang und läuft auf den gängigen Betriebssystemen. Später kannst du da nach Belieben etwas vorschalten und, im Falle einer WSGI-Anwendung, den Unterbau austauschen.

Würde wohl zu SQLAlchemy raten.

Ich dir auch. Rein mit SQL gegen ein spezielles DBMS zu programmieren, wäre mir sowohl zu umständlich als auch zu unflexibel. Optimieren kann man dann immer noch, und bzgl. der Erzeugung von angepassten Queries ist man mit SA auch sehr flexibel.

Ich sehe allerdings dein Problem mit Genshi nicht, an welche Stelle stört dich XML

Ich denke, dass es in meinem Fall besser ist Python Code direkt eingebaut zu haben, da ich so eher so eine Art Browsergame realisieren kann, aber vielleicht irre ich mich da auch.

Mir scheint, du verwechselst da was. Template Engines sollen primär die Präsentation auslagern, Code hat da im reinsten Sinne nichts drin verloren. Und ja, gerade wenn du Websites erstellen willst (sowohl mit XHTML als auch mit XML-gefütterten Flash-Applets) bietet sich Genshi aufgrund der XML-Orientierung an. Mako ist dennoch keine schlechte Wahl. Musst du selbst rausfinden, was dir besser gefällt (und ggf. eben später wechseln, das ist ja keine Schande, im Gegenteil).

[Yogi]

Dann habe ich ja für den Anfang eine vernünftige Basis:

Windows (später Debian) mit CherrPy, PostgreSQL, SQLAlchemy und Mako bzw. Genshi (da werde ich erst einmal das nehmen, wo ich mich wohler fühle und mal sehen).

Einzig was den Ersatz für Twisted betrifft (ist das wirklich overkill und so komplex? ) bin ich mir noch nicht sicher. Kamaelia ist wies aussieht nur für Linux, Allegra blicke ich noch nicht durch, Medusa wurde schon seit 2003 nicht mehr angepackt, und zu asyncore habe ich zumindest ein nettes Tut gefunden (asyncore Tut). Aber wo finde ich was zu der Verwendung der Protokolle UDP und TCP? Ich konnte nicht erkennen, dass die direkt in diesen Paketen unterstützt werden.