KnowHow - Software - Python - Mein Hintergrund

Ich lerne Python. Oder genauer: Ich lerne Python jetzt etwas genauer kennen.

Python ist eine nette Sprache. Sie ist für alle mir wichtigen Plattformen verfügbar (Linux und Windows), kennt GUIs und gegenüber Perl haben Python-Scripte nicht die Tendenz in spätere Unverständlichkeit zu versinken.

Die Problemstellung

Um Python effektiv einsetzen zu können habe ich folgende Probleme:

Wie deployt man ein fertiges Programm? Eine Anleitung a la "Downloade Python, dann downloade folgendes Library, dann downloade mein Programm, und wenn Du alles richtig gemacht hast dann kommt was" ist nicht brauchbar. Es muss sich so deployen:
Im Web ist ein Link. Da klickt man drauf. Den Download speichert man irgendwo, startet ihn und das Programm rennt.
So dass die Leute (für Windows) nur auf den richtigen Link klicken müssen. Das muss auch für Leute funktionieren die keine administrativen Rechte unter ihrem Windows haben. Also: Python installieren ist nicht, reboot er recht nicht! Es kann auf einem fertigen Python aufsetzen, aber prinzipiell muss die Runtime mit runterkommen, also ein fertig kompiliertes Programm. Mit VB habe ich das hinbekommen. Mit Java nicht.
Wie baut man damit schnell eine GUI auf? (Mit HTML und VB funktioniert das, alles andere war mir bisher einfach viel zu kompliziert.) Mich interessiert hier nicht, irgendetwas super-duper perfektes hinzuklatschen, sondern es muss etwas sein, das funktioniert und nicht zu lange aufhält, und hinterher bedienbar ist. In VB ist das so, man nimmt einen Button, klebt den da hin wo man ihn haben will und baut das Script, das abläuft wenn der Button kommt. Ähnlich einfach ist es Listen usw. zu bauen. Es muss gar nicht grafisch sein, es kann auch so funktionieren wie bei HTML, das ist vollkommen ausreichend. Wichtig ist nur, die GUI darf nicht komplizierter sein, sie muss so schnell und einfach funktionieren wie diese beiden Beispiele.
Wie bekommt man das Ding in den Tray? Ich schreibe Tools. Tools bedeutet, das sind nicht irgendwelche Applikationen, die im Vordergrund rennen, sondern die im Hintergrund ihren Dienst tun müssen. Permanent. Und die Leute müssen dieses Teil auch bedienen können. Also muss es in den Tray. Nur, wie geht das? Der Tray muss unter Windows funktionieren. Unter X-Window kann ich mir ggf. anders helfen, aber es wäre schön, wenn es da auch genauso klappen würde (also irgendein Lib gibt, das es auf den jeweiligen Plattformen für mich macht).

Die hier beschriebenen Probleme habe ich in jeder Programmiersprache und mit jedem Programmiersystem. Es sind die "Essentials" die ich als Entwickler benötige. Schön wäre, wenn ich endlich mal etwas finden würde, das das plattformübergreifend und einfach erledigen würde.

Bisher also mache ich das so:

Deploy: Ich schreibe und veröffentliche derzeit nur Source-Code
GUI: Per Web
Tray: Per VB (das Ding bringt dann eine IE-Komponente hoch in der alles abläuft)

Das alles ist vollkommen unbefriedigend!

Lieber hätte ich eine Lösung, die mir die Sachen in mehrere Teile zerlegt:

Ein GUI-Tray-Backend: Das ist ein Teil, das sitzt im Tray, und das liefert mir die GUI für Tool-Scripte. Der Trick ist dann, die Scripte brauchen selber keine GUI, die haben eine Beschreibung (z. B. HTML) die vom Script unabhängig ist. Das Script läuft dann ab und interagiert mehr oder weniger elegant mit der GUI.
Ein Scripting-Frontend: Das ist ein Container, in dem die Scripte ablaufen. Als Threads, als Programme, als was auch immer. Dieser ist dann vollkommen unabhängig von der GUI. Wichtig ist, dass solche Scripts nicht wie Servlets ablaufen, sondern modal-artig. D. h. etwas berechnet etwas und "zeigt" einen Fortschrittsbalken an. Dazu updatet es nur die Fortschritts-Variable (Class), die denn in der GUI in einen Balken dargestellt wird, wobei beides vollkommen voneinander abgekoppelt ist (also hält man die GUI an läuft das Script weiter und umgekehrt).

Und ja, ich habe die Begriffe "Frontend" und "Backend" richtig herum verwendet. Das ist genauso "verdreht" wie bei X-Window, bei dem der Server das Display ist und der Client das Programm. Beides liegt daran, dass man es hier nicht aus User-Sicht sieht, sondern aus der Sicht des ablaufenden Programms. Ich schreibe Tools, d. h. mir liegt nichts ferner als die GUI! Aus der Sicht von Tools ist die GUI ein Backend (eine Ausgabe) und nicht ein Frontend (die Eingabe).

Hoffnung Python

Python ist eine Scripting-Sprache, die man hoffentlich genau da hindrehen kann wo ich es haben will. D. h. man baut sich (mit der Zeit!) eine Klassenbibliothek zusammen, über die man dann "plötzlich" alles umdrehen kann ohne dass sich die Scripte verändern müssen.

In Perl geht das so nicht, oder nicht so einfach. Java ist der reine Abschuss in dieser Sache, das System wurde leider vollkommen falsch herum aufgesetzt. .NET ist nur eine Runntime, nettes Spielzeug, kann aber das nicht was ich eigentlich will und ist nicht portabel. Am besten skaliert in diesem Sinne HTML, d. h. der Output vom Script ist die GUI. Nicht ideal, aber vom Ansatz her brauchbar.

-Tino, 2007-03-30