Das deutsche Python-Forum

Edit (Leonidas): Aus dem Thread "pygen" ausgeschnitten.

Leonidas hat geschrieben:
Costi hat geschrieben:
wofür sollte sowas gut sein?
@Leonidas: pls naechstes mal konstruktiv und begruendet kritisieren
Der Kommentar war sowohl konstruktiv als auch begründet. Ich führe mal aus:

Und ich verteidige ihn mal ...

Leonidas hat geschrieben:

du hast einfach irgendeinen schwer lesbaren Code in das Forum geschmissen mit der Begründung dass er selbsterklärend ist. Ist er aber nicht.

Komisch, ich habe nämlich verstanden, um was es ihm ging. Zum einen ist der Name "Pygen" doch ein deutlicher Hinweis darauf, dass da was generiert wird, zum anderen sind die Namen der Methoden stark inn Bezug zu Python gesetzt. Die Tatsache, dass dann noch Python-Operatoren und Schlüsselworte im Rahmen einer String-Konkatenation zurückgegeben werden, macht die Sache dann doch eigentlich klar, oder?

Leonidas hat geschrieben: [*]Wofür braucht man einen Codegenarator in Python? Es gibt Metaklassen, Dekoratoren etc. schon in Python eingebaut also wozu soll das gut sein?[/list]

Ein Beispiel: KeyJnote liest Beschreibungsdateien ein, welche als Python-Modul interpretiert werden und dementsprechend auch korrekten Code enthalten müssen. Nehmen wir einfach mal an, jemand möchte einen kleinen GUI Editor für diese Dateien schreiben ...

Leonidas hat geschrieben:Du siehst, sowohl konstruktive als auch begründete Kritik.

Du siehst, man kann jede Kritik widerlegen

Edit (Leonidas): Markup repariert.
Edit (Leonidas): Aus dem Thread "pygen" ausgeschnitten.

lunar hat geschrieben:Komisch, ich habe nämlich verstanden, um was es ihm ging. Zum einen ist der Name "Pygen" doch ein deutlicher Hinweis darauf, dass da was generiert wird, zum anderen sind die Namen der Methoden stark inn Bezug zu Python gesetzt. Die Tatsache, dass dann noch Python-Operatoren und Schlüsselworte im Rahmen einer String-Konkatenation zurückgegeben werden, macht die Sache dann doch eigentlich klar, oder?

Also findest du ok einen undokumentierten Code zu lesen, der zudem noch umständlich geschrieben ist und zu raten wofür der gut ist? Also als ich mal versucht habe eine seltsame Django-Funktion zu verstehen (um zu ermitteln ob sie überhaupt die richtige Ausgabe produziert) bin ich dank fehlender Dokumentation (Docstring oder einiger Worte von den Entwicklern) nicht sehr weit gekommen.

Und was den GUI-Editor angeht, habe ich den starken Verdacht, dass es einfacher ist, Codestückchen in eine Datei zu schreiben als über diese API etwas zu konstruieren (und kürzer). Ist von dem her einfacher, dass es keinen zusätzlichen "Layer of indirection" gibt. Stell dir den unwarscheinlichen Fall vor, dass ein Programm von Costi mal nicht so funktioniert wie gewollt, sondern zum Beispiel durch einen Bug falsch einrückt. Dann müsste der Entwickler des Quellcodes erstmal Pygen debuggen. Oder noch warscheinlicher: jemand will einen Python-Code schreiben, der etwasw kann, was Pygen nicht abdeckt, wie etwa imports oder Docstrings, oder LCs, oder return, oder die neue if-Syntax die in Python 2.5 dazugekommen ist, oder Dekoratoren oder sonstige Konstrukte.
Für simples reicht das, für komplexeres wird das formulieren des Codes mit Pygen exponentiell komplexer (angenommen man könnte mit Pygen überhaupt komplexen Code generieren, was im Moment ja nicht der Fall ist).

Ich kenne das Format von KeyJnode nicht, aber wenn die Dateien simpel sind, dann lohnt sich Pygen nicht und wenn sie komplexer sind, dann ist ein Solcher Codegenerator auch recht unbrauchbar, weil er das ganze noch komplizierter macht.

lunar hat geschrieben:
Leonidas hat geschrieben:Du siehst, sowohl konstruktive als auch begründete Kritik.
Du siehst, man kann jede Kritik widerlegen

Nur ob es auch auch gelingt ist eine andere Sache.

Klar, kann jeder selbst entscheiden, ob er einen Python-Codegenerator braucht - wxGlade hat mal einen Codegenerator gehabt, aber ich habe selbst eh' lieber XRC benutzt, weil man das auch wieder editieren konnte. Die Anwendungsfälle eines Python-Codegenerators sind nur eben sehr beschränkt.

Leonidas hat geschrieben:
lunar hat geschrieben:Komisch, ich habe nämlich verstanden, um was es ihm ging. Zum einen ist der Name "Pygen" doch ein deutlicher Hinweis darauf, dass da was generiert wird, zum anderen sind die Namen der Methoden stark inn Bezug zu Python gesetzt. Die Tatsache, dass dann noch Python-Operatoren und Schlüsselworte im Rahmen einer String-Konkatenation zurückgegeben werden, macht die Sache dann doch eigentlich klar, oder?
Also findest du ok einen undokumentierten Code zu lesen, der zudem noch umständlich geschrieben ist und zu raten wofür der gut ist?

Ich habe nicht gesagt, dass ich das ok finde! Ich habe lediglich festgestellt, dass mir der Code (oder zumindest die Intention) in diesem Fall relativ schnell klar war. Der Code ist ja nun mit gerade einmal 50 Zeilen auch nicht sonderlich komplex, um ehrlich zu sein.

Das Docstrings und Kommentare in jeden Code gehören, ist ja wohl klar! Aber das an diesem Mini-Code festzumachen, war etwas übertrieben ...

Leonidas hat geschrieben:Für simples reicht das, für komplexeres wird das formulieren des Codes mit Pygen exponentiell komplexer (angenommen man könnte mit Pygen überhaupt komplexen Code generieren, was im Moment ja nicht der Fall ist).

Ich habe auch nicht behauptet, dass Costis Code ein guter Generator ist, oder zum Programmieren eines solchen GUI Editors sinnvoll wäre. Mit ging es lediglich um deine Behauptung, man brächte keinen Code-Generator, welche in meinen Augen so pauschal schlicht falsch ist.
Insofern war das Beispiel mit dem GUI Editor lediglich eine Antwort auf deine Frage: "Wofür braucht man einen Codegenarator in Python?"

Leonidas hat geschrieben:Ich kenne das Format von KeyJnode nicht, aber wenn die Dateien simpel sind, dann lohnt sich Pygen nicht und wenn sie komplexer sind, dann ist ein Solcher Codegenerator auch recht unbrauchbar, weil er das ganze noch komplizierter macht.

Ich würde diesen Generator auch nicht dafür verwenden. Für KeyJnote reichen " ''.join" und "file"

Leonidas hat geschrieben:
lunar hat geschrieben:
Leonidas hat geschrieben:Du siehst, sowohl konstruktive als auch begründete Kritik.
Du siehst, man kann jede Kritik widerlegen
Nur ob es auch auch gelingt ist eine andere Sache.

Naja, ich finde, in diesem Fall ist es mir halbwegs gelungen

Leonidas hat geschrieben:Die Anwendungsfälle eines Python-Codegenerators sind nur eben sehr beschränkt.

Es gibt sie aber. Ein weiteres Beispiel ist z.B. pyuic, der aus QTDesigner Dateien Python Module erzeugt. Klar sieht der Code nicht schön aus, aber in diesem Fall braucht er das ja auch nicht zu sein. Die GUI bearbeite ich sowieso nicht im Code, sondern eben mit dem Designer. Dann ist es egal, wie mies der Code aussieht, weil ich ihn sowieso nie anschaue.

lunar hat geschrieben:Ich habe nicht gesagt, dass ich das ok finde! Ich habe lediglich festgestellt, dass mir der Code (oder zumindest die Intention) in diesem Fall relativ schnell klar war. Der Code ist ja nun mit gerade einmal 50 Zeilen auch nicht sonderlich komplex, um ehrlich zu sein.

Ok, komplex ist der nicht. Wenn sich aber jeder so viel Mühe bei Postings geben würde wie Costi müsste eigentlich niemand auf diesen Thread antworten. Er hat den Code einfach nur so reingeworfen, nach dem Motto: "Ich habe was geschrieben und brauche das Python-Forum als Poor-Mans-SVN". Weder eine bitte nach Verbesserungsvorschlägen noch irgendwas anderes. Ein Thread ohne Frage. Ergo: "ignoriert diesen Thread bitte". Wenn ich nicht daruauf reagiert hätte dann ist es gut möglich, dass niemand dazu etwas geschrieben hätte - wozu auch?

lunar hat geschrieben:Das Docstrings und Kommentare in jeden Code gehören, ist ja wohl klar! Aber das an diesem Mini-Code festzumachen, war etwas übertrieben ...

Hast an dieser Stelle recht. Aber man könnte einen Docstring machen, warum es überhaupt _space1 und _space2 gibt (ergo warum die Funktionalität nicht in einer Funktion _space mit Keywort-Argument ist) und warum man ClassDef nutzen sollte, wenn doch ``def``s in Klassen auch nur ``def``s sind. Oder wo ``self.iDef`` versteckt ist (also irgendwie bin ich blind, denn ob ihr es mir glaubt oder nicht, ich finde es echt nicht).

lunar hat geschrieben:Mit ging es lediglich um deine Behauptung, man brächte keinen Code-Generator, welche in meinen Augen so pauschal schlicht falsch ist.

Gut, zugegeben, etwas arg pauschal. Manchmal braucht man Codegeneratoren in Python. Jedoch wesentlich seltener als in anderen Programmiersprachen.

lunar hat geschrieben:Es gibt sie aber. Ein weiteres Beispiel ist z.B. pyuic, der aus QTDesigner Dateien Python Module erzeugt. Klar sieht der Code nicht schön aus, aber in diesem Fall braucht er das ja auch nicht zu sein. Die GUI bearbeite ich sowieso nicht im Code, sondern eben mit dem Designer. Dann ist es egal, wie mies der Code aussieht, weil ich ihn sowieso nie anschaue.

Das würde ich aber als Beschränkung von Qt sehen, denn als sinnvollen Anwendungsfall für Codegeneratoren (wie ich schon im wxGlade-Beispiel angedeutet habe). Andere Toolkits können ihre UI-Beschreibungsdateien selbst lesen und aus diesen sofort die UI laden (GTK+ über Glade-Dateien, wxWidgets über XRC-Dateien, Windows MFC nutzt auch schon seit langem Resource-Files die in die EXE-Datei eingebunden werden). Und PyQt zieht an der Stelle auch nach, mit PyUIC und seit PyQt4 mit uic.

Leonidas hat geschrieben:
lunar hat geschrieben:Mit ging es lediglich um deine Behauptung, man brächte keinen Code-Generator, welche in meinen Augen so pauschal schlicht falsch ist.
Gut, zugegeben, etwas arg pauschal. Manchmal braucht man Codegeneratoren in Python. Jedoch wesentlich seltener als in anderen Programmiersprachen.

Stimmt... Wenn ich daran denke, dass man in Java/C# schon mal Code-Generatoren für Listen verwendet hat ... Brrr, da bin ich froh, dass ich bei Python gelandet bin

Leonidas hat geschrieben:
lunar hat geschrieben:Es gibt sie aber. Ein weiteres Beispiel ist z.B. pyuic, der aus QTDesigner Dateien Python Module erzeugt. Klar sieht der Code nicht schön aus, aber in diesem Fall braucht er das ja auch nicht zu sein. Die GUI bearbeite ich sowieso nicht im Code, sondern eben mit dem Designer. Dann ist es egal, wie mies der Code aussieht, weil ich ihn sowieso nie anschaue.
Das würde ich aber als Beschränkung von Qt sehen, denn als sinnvollen Anwendungsfall für Codegeneratoren (wie ich schon im wxGlade-Beispiel angedeutet habe). Andere Toolkits können ihre UI-Beschreibungsdateien selbst lesen und aus diesen sofort die UI laden (GTK+ über Glade-Dateien, wxWidgets über XRC-Dateien, Windows MFC nutzt auch schon seit langem Resource-Files die in die EXE-Datei eingebunden werden).

Naja, ob das eine "Beschränkung" ist ... Imho ist es doch egal, ob nun aus der Beschreibungsdatei (zur Laufzeit oder davor) Code generiert wird, oder ob es nun Code gibt, der die Datei zur Laufzeit interpretiert. Beides funktioniert.
Die "Interpreter" solcher GUI Dateien machen ja eigentlich auch nichts anderes, als zur Laufzeit Code zum Erzeugen dieser GUI Widgets auszuführen. Der Unterschied ist doch eigentlich nur, dass der Code da nicht gespeichert wird.
Echte Vor- oder Nachteile hat keine der beiden Methoden.

Leonidas hat geschrieben:Und PyQt zieht an der Stelle auch nach, mit PyUIC und seit PyQt4 mit uic.

Soweit ich das verstanden habe, passiert da aber auch nichts anderes als ein interner Aufruf von pyuic. Das ist mit den pykdeextensions schon jetzt möglich.

lunar hat geschrieben:Die "Interpreter" solcher GUI Dateien machen ja eigentlich auch nichts anderes, als zur Laufzeit Code zum Erzeugen dieser GUI Widgets auszuführen. Der Unterschied ist doch eigentlich nur, dass der Code da nicht gespeichert wird.
Echte Vor- oder Nachteile hat keine der beiden Methoden.

Der Unterschied ist, dass da (zumindest im Fall der libglade, mit der ich mich besser auskenne als mit Qt) kein Python-Code generiert wird der danach ausgeführt wird. Wenn du eine Datei parst, führst du sie ja in der Regel auch nicht in Python-Code um, um daraus dann eine Datenstruktur zu erstellen mit der man arbeiten kann.
Und das du direkt die Datei verändern kannst die letztendlich als GUI verwendet wird hat den Vorteil, dass du dir die Proxy-Datei sparst, die sonst eben nicht zum editieren wäre. Änderungen müssten erstmal über das GUI-Tool laufen, welches eine UIC-Datei erzeugt, welche danach in Python-Code umgewandelt werden muss.

Apropos Codegeneration: moc war auch einer der Kritikpunkte an Qt. Inzwischen, so habe ich es gelesen, könnte man das was moc macht auch über Templates lösen:

Wikipedia, die ultimative Quelle alles Wissens und aller Wahrheit ;) hat geschrieben:Als Qt 1.x veröffentlicht wurde, waren die Compilerunterschiede bezüglich generischer Programmierung noch zu groß, als dass man sich auf Templates hätte verlassen können, wie dies zum Beispiel im Boost-Toolkit der Fall ist.

lunar hat geschrieben:Soweit ich das verstanden habe, passiert da aber auch nichts anderes als ein interner Aufruf von pyuic. Das ist mit den pykdeextensions schon jetzt möglich.

Soweit das PyUIC betrifft schon. Aber ich weiß nicht, ob sich PyQt4 nicht schon so wie die libglade verhält. Habe aber nicht in die Interna geschaut und aus der Dokumentation die ich gesehen habe kommt das nicht herraus.

lunar hat geschrieben:Naja, ob das eine "Beschränkung" ist ... Imho ist es doch egal, ob nun aus der Beschreibungsdatei (zur Laufzeit oder davor) Code generiert wird, oder ob es nun Code gibt, der die Datei zur Laufzeit interpretiert. Beides funktioniert.
Die "Interpreter" solcher GUI Dateien machen ja eigentlich auch nichts anderes, als zur Laufzeit Code zum Erzeugen dieser GUI Widgets auszuführen. Der Unterschied ist doch eigentlich nur, dass der Code da nicht gespeichert wird.
Echte Vor- oder Nachteile hat keine der beiden Methoden.

Die GUI-Dateien haben den echten Vorteil das sie unabhängig von der Programmiersprache sind.

BlackJack hat geschrieben:
lunar hat geschrieben:Naja, ob das eine "Beschränkung" ist ... Imho ist es doch egal, ob nun aus der Beschreibungsdatei (zur Laufzeit oder davor) Code generiert wird, oder ob es nun Code gibt, der die Datei zur Laufzeit interpretiert. Beides funktioniert.
Die "Interpreter" solcher GUI Dateien machen ja eigentlich auch nichts anderes, als zur Laufzeit Code zum Erzeugen dieser GUI Widgets auszuführen. Der Unterschied ist doch eigentlich nur, dass der Code da nicht gespeichert wird.
Echte Vor- oder Nachteile hat keine der beiden Methoden.
Die GUI-Dateien haben den echten Vorteil das sie unabhängig von der Programmiersprache sind.

Mmmh, dem kann ich so nicht zustimmen ...

Um Glade GUI Dateien zu verwenden, benötigt man libglade Bindings für die gewählte Sprache.
Um QT UI Dateien zu verwenden, benötigt man einen UI Compiler für die gewählte Sprache.

Die Unabhängigkeit von der Programmiersprache ist bei beiden Methoden einigermaßen gegeben...

Leonidas hat geschrieben: Und das du direkt die Datei verändern kannst die letztendlich als GUI verwendet wird hat den Vorteil, dass du dir die Proxy-Datei sparst, die sonst eben nicht zum editieren wäre. Änderungen müssten erstmal über das GUI-Tool laufen, welches eine UIC-Datei erzeugt, welche danach in Python-Code umgewandelt werden muss.

Im Falle von C++ ist das imho sowieso egal... Wer ändert den schon die GUI ohne neu zu kompilieren. Wenn ich mir die GUI nur anschauen will, dann kann ich das auch im Designer selbst. Und wenn man dann das Programm testet, wird vorher sowieso neu compiliert, wobei uic auch einmal durchläuft.
Bei Python ist es letztlich auch egal, weil die pykdeextensions pyuic zur Laufzeit ausführen. Man merkt also gar nicht, dass im Hintergrund Dateien erzeugt werden.
Die vom uic erzeugten C++/py Dateien fasst man normalerweise nie an. Die sind halt einfach da ...

Leonidas hat geschrieben:Apropos Codegeneration: moc war auch einer der Kritikpunkte an Qt. Inzwischen, so habe ich es gelesen, könnte man das was moc macht auch über Templates lösen:
Wikipedia, die ultimative Quelle alles Wissens und aller Wahrheit ;) hat geschrieben:Als Qt 1.x veröffentlicht wurde, waren die Compilerunterschiede bezüglich generischer Programmierung noch zu groß, als dass man sich auf Templates hätte verlassen können, wie dies zum Beispiel im Boost-Toolkit der Fall ist.

Moc allein durch Templates zu ersetzen ist imho nicht möglich. Moc emuliert nämlich auch Features der rtti. Man kann mittels des von Moc generierten Quellcodes z.B. den Klassenname und die Vererbungshierachie zur Laufzeit ausgeben (so ähnlich wie die Reflection API bei Java). Besonders ersteres ist wiederrum wichtig, damit i18n mit QT richtig funktioniert ...

lunar hat geschrieben:Mmmh, dem kann ich so nicht zustimmen ...

Um Glade GUI Dateien zu verwenden, benötigt man libglade Bindings für die gewählte Sprache.

Um QT UI Dateien zu verwenden, benötigt man einen UI Compiler für die gewählte Sprache.
Die Unabhängigkeit von der Programmiersprache ist bei beiden Methoden einigermaßen gegeben...

Ja, aber einen UI-Compiler braucht man für die gegebene Sprache, muss also das Parsen und Codegenerieren für jede Sprache gesondert erstellen. libglade erstellt gleich die GTK-Widgets im Speicher, also gibt es einen universellen glade-Parser, nämlich die libglade, deren Interfaces durch Bindings an die Sprache weitergegeben wird. So muss PyQt selbst einen UIC-Parser bereitstellen, aber PyGTK, gtkmm, java-gnome, gtk2-perl nutzen die gleiche, von libglade bereitgestellte Funktionalität. Hat auch den Vorteil, dass wenn das Glade-Format erweitert werden würde, dann müsste man nur die libglade anpassen - da keines der GTK-Bindings Glade-Dateien selbst parst würden alle automatisch das neue Format verstehen. Der Vorteil ist bei einem Codegenerator wie PyUIC nicht gegeben, dort muss jedes Binding sich selbst up-to-date halten.

Man könnte noch den EInfanw der Performance einbringen, aber das parsen von aus-UIC-erstellen-Python-Dateien oder GLADE-Dateien dauert auf aktuellen Systemen sowieso nicht lange, daher ist "vorparsen" durch PyUIC nicht sonderlich viel schneller als das parsen-beim-laden von libglade. Könnte sogar noch andersrum sein, da libglade in C geschrieben ist. Aber das jetzt nachzumessen ist mir jetzt zuviel Arbeit.

Übrigens, durch meine ursprüngliche Kritik sind wir immerhin zu einer Interessanten Diskussion gekommen. Das ist schon mal was. Ich trenne sie mal ab, da wir vom ursprünglichen Thema schon ziemlich entfernt sind.

Da ich das mit dem Splitting wieder nicht korrekt hinbekommen habe, hier nochmal BlackJacks Antwort.

BlackJack hat geschrieben:
lunar hat geschrieben:
BlackJack hat geschrieben:Die GUI-Dateien haben den echten Vorteil das sie unabhängig von der Programmiersprache sind.
Mmmh, dem kann ich so nicht zustimmen ...

Um Glade GUI Dateien zu verwenden, benötigt man libglade Bindings für die gewählte Sprache.

Um QT UI Dateien zu verwenden, benötigt man einen UI Compiler für die gewählte Sprache.
Inwiefern macht das jetzt die Datei mit der GUI-Beschreibung abhängig von der Programmiersprache? Wenn mir der Designer Code für Python ausspuckt, kann ich den nicht für ein C Programm verwenden. Eine Datei mit der GUI-Beschreibung ist dagegen unabhängig von der Programmiersprache. Ich kann einen Prototyp in Sprache X entwerfen und die GUI-Beschreibung dann für die spätere Implementierung in Sprache Y wiederverwenden. Da sind Daten und Code strikter voneinander getrennt. Ist im Grunde das gleiche wie die wünschenswerte Trennung von Darstellung und Logik bei Webframeworks.

Leonidas hat geschrieben:
lunar hat geschrieben:Mmmh, dem kann ich so nicht zustimmen ...

Um Glade GUI Dateien zu verwenden, benötigt man libglade Bindings für die gewählte Sprache.

Um QT UI Dateien zu verwenden, benötigt man einen UI Compiler für die gewählte Sprache.
Die Unabhängigkeit von der Programmiersprache ist bei beiden Methoden einigermaßen gegeben...
Ja, aber einen UI-Compiler braucht man für die gegebene Sprache, muss also das Parsen und Codegenerieren für jede Sprache gesondert erstellen. libglade erstellt gleich die GTK-Widgets im Speicher, also gibt es einen universellen glade-Parser, nämlich die libglade, deren Interfaces durch Bindings an die Sprache weitergegeben wird. So muss PyQt selbst einen UIC-Parser bereitstellen, aber PyGTK, gtkmm, java-gnome, gtk2-perl nutzen die gleiche, von libglade bereitgestellte Funktionalität. Hat auch den Vorteil, dass wenn das Glade-Format erweitert werden würde, dann müsste man nur die libglade anpassen - da keines der GTK-Bindings Glade-Dateien selbst parst würden alle automatisch das neue Format verstehen. Der Vorteil ist bei einem Codegenerator wie PyUIC nicht gegeben, dort muss jedes Binding sich selbst up-to-date halten.

Da hast du allerdings recht! Daran hab' ich gar nicht gedacht ... Aber im Bezug auf QT sehe ich da auch keinen großen Nachteil, da dass Format sich höchstens mal beim Sprung in der Major-Versionsnummer (QT 3 -> QT 4) ändert. In diesem Fall müssen aber sowieso alle Bindings angepasst werden, da QT bei solchen Sprung auch immer recht große Änderungen in den APIs mitbringt. Dazwischen passiert aber eher wenig im Bezug auf die Designer-Dateien. Bei GTK kann das aber möglicherweise anders aussehen.

Einen großer Nachteil des Generators ist allerdings, dass er außer QT keine Imports hinzufügt. Auch die pykdeextensions fügen nur noch kdecore und kdeui hinzu. Wenn man aber die nützlichen Widgets aus kdepim oder kfile verwendet, muss man die Imports selbstständig zum Modul hinzufügen

:

Code: Alles auswählen

from kfile import KFile, KURLRequester

import kdedesigner
import settingswidget

# pykdeextensions do add imports for kdecore and kdeui, but not for
# kfile. So we need to import KURLRequester and add it to the
# globals() dict of settingswidget.
settingswidget.KURLRequester = KURLRequester

Dafür kann man dann aber die coolen KDE Widgets verwenden ... KDE rockt einfach

Leonidas hat geschrieben: Man könnte noch den EInfanw der Performance einbringen, aber das parsen von aus-UIC-erstellen-Python-Dateien oder GLADE-Dateien dauert auf aktuellen Systemen sowieso nicht lange, daher ist "vorparsen" durch PyUIC nicht sonderlich viel schneller als das parsen-beim-laden von libglade. Könnte sogar noch andersrum sein, da libglade in C geschrieben ist. Aber das jetzt nachzumessen ist mir jetzt zuviel Arbeit.

Naja, das ist aber bei den heute üblichen Rechner sowieso relativ egal ...

BlackJack hat geschrieben:
lunar hat geschrieben:

Um Glade GUI Dateien zu verwenden, benötigt man libglade Bindings für die gewählte Sprache.

Um QT UI Dateien zu verwenden, benötigt man einen UI Compiler für die gewählte Sprache.
Inwiefern macht das jetzt die Datei mit der GUI-Beschreibung abhängig von der Programmiersprache? Wenn mir der Designer Code für Python ausspuckt, kann ich den nicht für ein C Programm verwenden.

Ja, aber die Designer Datei selbst ist eine einfache XML Datei, die von der jeweiligen Sprache unabhängig ist. Wenn du mit dem Designer arbeitest, dann hast du keinen Kontakt zu irgendeiner Programmiersprache.

BlackJack hat geschrieben: Eine Datei mit der GUI-Beschreibung ist dagegen unabhängig von der Programmiersprache. Ich kann einen Prototyp in Sprache X entwerfen und die GUI-Beschreibung dann für die spätere Implementierung in Sprache Y wiederverwenden.

Die GUI Beschreibung selbst ist wie auch bei Glade Dateien unabhängig von der gewählten Programmiersprache. Du kannst dieselbe Datei sowohl für C++ als auch für Python verwenden.

Nur der Weg der Anbindung an die Sprache unterscheidet sich. Bei Glade geschieht dies über Bindings für die libglade, bei QT über einen UI Compiler.

BlackJack hat geschrieben:
Da sind Daten und Code strikter voneinander getrennt. Ist im Grunde das gleiche wie die wünschenswerte Trennung von Darstellung und Logik bei Webframeworks.

Naja, die Trennung ist im Prinzip auch bei Code-Generatoren gegeben, da die Datei selbst ja unabhängig ist. Es wäre auch bei QT absolut möglich, anstatt des UI Compilers eine Bibliothek ähnlich der libglade zum Einlesen der GUI Beschreibung zu verwenden.

lunar hat geschrieben:Einen großer Nachteil des Generators ist allerdings, dass er außer QT keine Imports hinzufügt. Auch die pykdeextensions fügen nur noch kdecore und kdeui hinzu. Wenn man aber die nützlichen Widgets aus kdepim oder kfile verwendet, muss man die Imports selbstständig zum Modul hinzufügen :

Man kann die - ist zwar nicht sonderlich schön aber dennoch möglich - über Monkey-Patching einbinden.

Leonidas hat geschrieben:
lunar hat geschrieben:Einen großer Nachteil des Generators ist allerdings, dass er außer QT keine Imports hinzufügt. Auch die pykdeextensions fügen nur noch kdecore und kdeui hinzu. Wenn man aber die nützlichen Widgets aus kdepim oder kfile verwendet, muss man die Imports selbstständig zum Modul hinzufügen :
Man kann die - ist zwar nicht sonderlich schön aber dennoch möglich - über Monkey-Patching einbinden.

Was ich ja im gezeigten Snippet auch gemacht habe ... Nicht schön, aber solange es läuft

lunar hat geschrieben:Was ich ja im gezeigten Snippet auch gemacht habe ... Nicht schön, aber solange es läuft

Achso, 'tschuldige - habe ich übersehen.

Passend zum Thema Codegeneratoren gibt auch noch DSLs, besonders Rails nutzt solche. Daher werfe ich nun noch das Posting von PJE Schema Analysis and the need for Python-based DSLs welches sicherlich auch lesenswert ist. Über Google lassen sich noch mehr interessante Seiten und EuroPython-Slides zu dem Thema und dessen Vorteilen (und auch Nachteilen, die PJE auch schon angesprochen hat) finden.

Leonidas hat geschrieben:
lunar hat geschrieben:Einen großer Nachteil des Generators ist allerdings, dass er außer QT keine Imports hinzufügt. Auch die pykdeextensions fügen nur noch kdecore und kdeui hinzu. Wenn man aber die nützlichen Widgets aus kdepim oder kfile verwendet, muss man die Imports selbstständig zum Modul hinzufügen :
Man kann die - ist zwar nicht sonderlich schön aber dennoch möglich - über Monkey-Patching einbinden.

Das ist - wie inzwischen gemerkt habe - gar nicht nötig. Dabei hilft, dass pyuic die Kommentare einer Form, die man unter "Edit -> Form Settings" eingegen kann, interpretiert, sofern sie mit "Python:" beginnen. Der Kommentar "Python:from kfile import *" bindet dann auch KDE Widgets aus dem KFile Modul ein.

Genaueres steht in der Doku: http://www.riverbankcomputing.com/Docs/ ... html#AEN95

Das deutsche Python-Forum

Vorteile der Codegeneratoren, aber auch deren Nachteile

Vorteile der Codegeneratoren, aber auch deren Nachteile