Python + QT was braucht man alles

Python und das Qt-Toolkit, erstellen von GUIs mittels des Qt-Designers.
flyingeagle
User
Beiträge: 22
Registriert: Freitag 21. Juli 2006, 12:12

Hallo,

Python programmier ich ab und an mal. Nun habe ich gesehen das man mit QT die Pythonprogramme huebsch machen kann :).

Was brauht man denn alles dazu und woher bekommt man es? Gibts ein paar gute Dokus dafuer? Ich wuerde unter Windows entwickeln.

Gruss Martin
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Python + PyQt. Hmm, das wars schon. Du willst sicher noch einen Editor haben, aber sonst hast du schon alles.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
flyingeagle
User
Beiträge: 22
Registriert: Freitag 21. Juli 2006, 12:12

hi,

denke fuer deine Antwort, leider klappt das ganze nicht so wirklich.

ich habe Python 2.5 bei mir auf dem System, nun hab ich noch die PyQt-Py2.5-gpl-4.3.3-2.exe heruntergeladen und installiert.

will ich ein einfaches "hallo Welt" starten bekomm ich folgenden Fehler
File "bla.py", line 37, in <module>
import qt
ImportError: No module named qt
Was fehlt mir noch?

Gruss Martin
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

flyingeagle hat geschrieben:will ich ein einfaches "hallo Welt" starten
Naja, das ist ja auch für PyQt3. Funktioniert also nicht.

Nimm lieber den Code:

Code: Alles auswählen

import sys
from PyQt4.QtGui import QApplication, QPushButton
app = QApplication(sys.argv)
button = QPushButton("Hello World", None)
button.show()
app.exec_()
P.S.: Warum kann PyQt nicht auch Namespaces nutzen statt der Prefixes? Das fördert schon wieder diese blöden Starn-Imports... :shock:
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
flyingeagle
User
Beiträge: 22
Registriert: Freitag 21. Juli 2006, 12:12

hi,

danke fuer die Antwort, jetzt klappt es.

Dann werd ich mal ein bisschen mit dem Zeugs rumspielen :)


Gruss Martin
burli
User
Beiträge: 1156
Registriert: Dienstag 9. März 2004, 18:22

Hi,
unter Win brauchst du nur das Komplettpaket von Riverbankcomputing und Python 2.5

Was ich noch empfehlen kann ist das Buch von Mark Summerfield. Ich habe online bisher noch keine so gute Referenz gefunden die das verständlich und ausführlich erklärt
lunar

Leonidas hat geschrieben:P.S.: Warum kann PyQt nicht auch Namespaces nutzen statt der Prefixes? Das fördert schon wieder diese blöden Starn-Imports... :shock:

Code: Alles auswählen

import sys
from PyQt4 import QtGui
app = QtGui.QApplication(sys.argv)
button = QtGui.QPushButton("Hello World")
button.show()
app.exec_()
Überlass die Beispiele das nächste Mal denen, die Ahnung von PyQt4 haben, oder zumindest fähig sind, einen Blick in die Doku zu werfen, dann musst du auch keinen FUD verbreiten.
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Lunar, dein Beispiel ändert aber an den unschönen prefixes nichts ;)
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
burli
User
Beiträge: 1156
Registriert: Dienstag 9. März 2004, 18:22

In den Beispielen in meinem Buch wird immer so importiert

Code: Alles auswählen

from PyQt4.QtGui import *
from PyQt4.QtCore import *
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

lunar hat geschrieben:Überlass die Beispiele das nächste Mal denen, die Ahnung von PyQt4 haben, oder zumindest fähig sind, einen Blick in die Doku zu werfen, dann musst du auch keinen FUD verbreiten.
Ich habe das Beispiel aus irgendeiner Seite, die da was von PyQt4 geschrieben hat - dort waren auch noch Stern-Imports weil es natürlich reichlich unbequem ist, immer QtGui, QtCore, QtSomething vor irgendwas zu hängen, wenn die einzelnen Objekte zudem noch ein Q-Prefix haben.

Für die Python-Bindings hätten die da ruhig aufräumen können - die wxPython-Leute haben es schließlich auch geschafft die wxApp zu einer wx.App zu machen etc.

Und ja, ich weiß das QtGui einen Namespace bildet, dazu brauche ich auch keine PyQt-Doku. Aber der Q-Einwand bleibt und ich sehe, dass hier nach Tkinter die nächste Stern-Import-Katastrophe kommt. Im Gegensatz zu Tkinter gibt es hier aber auch keinen so tollen Ausweg. Man kann die QtSomething.QSomethingElse nutzen, aber ``qt.SomethingElse`` würde die es nicht herausfordern dass Leute Stern-Imports machen. Besonders da es sowieso zu keinen Kollisionen kommen würde (ich gehe davon aus, dass man alle PyQt-Namespaces gleichzeitig *-importieren kann).
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
lunar

Euch stört ein einziger Buchstabe? Habt ihr keine anderen Probleme? ;)
Leonidas hat geschrieben:Ich habe das Beispiel aus irgendeiner Seite, die da was von PyQt4 geschrieben hat - dort waren auch noch Stern-Imports weil es natürlich reichlich unbequem ist, immer QtGui, QtCore, QtSomething vor irgendwas zu hängen, wenn die einzelnen Objekte zudem noch ein Q-Prefix haben.
Fändest du das denn bequemer, wenn das Q nicht da wäre?

Sorry, aber ich vermag zwischen "QtGui.QApplication" und "QtGui.Application" keinen wirklichen Unterschied festzustellen.
Für die Python-Bindings hätten die da ruhig aufräumen können
Zu welchen Zweck? Damit alle immer erstmal Suchen-Und-Ersetzen drüber laufen lassen müssen, wenn sie C++-Code auf Python portieren? Damit C++-Programmierer sich schlechter mit Python-Programmieren unterhalten können?

Und ehrlich gesagt, ich empfinde das Q-Präfix nicht als "unordentlich", also sehe ich auch keinen Grund, dort "aufzuräumen".
Aber der Q-Einwand bleibt und ich sehe, dass hier nach Tkinter die nächste Stern-Import-Katastrophe kommt.
9/11 war eine Katastrophe, Perl ist eine Katastrophe, aber Sternchen-Imports von Tk? Das ist doch ein wenig übertrieben ;)
Im Gegensatz zu Tkinter gibt es hier aber auch keinen so tollen Ausweg. Man kann die QtSomething.QSomethingElse nutzen, aber ``qt.SomethingElse`` würde die es nicht herausfordern dass Leute Stern-Imports machen.
Ach? Qt3 hat "qt" als Modul-Namen genutzt, was die Leute nicht davon abgehalten hat, trotzdem Sternchen-Imports zu verwenden. Ebenso glaube ich nicht, dass "from wx import *" bei Anfängern nicht verbreitet ist. Sorry, aber ich denke, du dramatisierst.

"Profis" nutzen eh keine Sternchen-Imports, und Anfänger werden sich durch das Präfix nicht mehr angespornt sehen als bei anderen Modulen.
Die "os.path"-Katastrophe habe ich ebenso gesehen wie die "logging"-Katastrophe. PyQt ist da keine Ausnahme, sondern in guter Gesellschaft.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

lunar hat geschrieben:Fändest du das denn bequemer, wenn das Q nicht da wäre?
Wenns qt.Application wäre - ja, durchchaus. Würdest du denn gerne logging.LStreamHandler und logging.LSocketHandler haben?
lunar hat geschrieben:
Für die Python-Bindings hätten die da ruhig aufräumen können
Zu welchen Zweck? Damit alle immer erstmal Suchen-Und-Ersetzen drüber laufen lassen müssen, wenn sie C++-Code auf Python portieren? Damit C++-Programmierer sich schlechter mit Python-Programmieren unterhalten können?
Das ist doch quatsch. An den Namen wirds am wenigsten scheitern. Eher werden sich die C++-Leute wundern was denn diese Properties oder Duck Typing sind. APIs ungeändert übernehmen ist zwar einfach, aber du stimmst mir doch sicher zu, dass die aus anderen Sprachen übernommenen APIs von Minidom, Logging und pywin32 alles andere als komfortabel sind (die API von wxPython finde ich auch etwas arg C++-mäßig, aber da arbeiten sie seit mehreren Releases dran, so etwa sind die Prefixes weg, die IDs sind am aussterben etc). Daher bin ich durchaus dafür in vernünftigen Maße die APIs umzukrempeln.

Wenn du mal was zum lachen haben willst, dann schau dir mal die API von JanRains OpenID-Lib an. Das ist mal grausam, was die da zusammengebaut haben.
lunar hat geschrieben:Und ehrlich gesagt, ich empfinde das Q-Präfix nicht als "unordentlich", also sehe ich auch keinen Grund, dort "aufzuräumen".
Unordentlich nicht, aber schlichtweg unnötig. Es bringt keinen Verständnisgewinn. Ungarische Notation war in VB mal in :)
lunar hat geschrieben:
Im Gegensatz zu Tkinter gibt es hier aber auch keinen so tollen Ausweg. Man kann die QtSomething.QSomethingElse nutzen, aber ``qt.SomethingElse`` würde die es nicht herausfordern dass Leute Stern-Imports machen.
Ach? Qt3 hat "qt" als Modul-Namen genutzt, was die Leute nicht davon abgehalten hat, trotzdem Sternchen-Imports zu verwenden. Ebenso glaube ich nicht, dass "from wx import *" bei Anfängern nicht verbreitet ist. Sorry, aber ich denke, du dramatisierst.
Seit der Umstellung von ``wxPython.wx`` und den wx-Prefixes zum wx-Namensraum sehe ich weniger. Das haben die auch recht konsequent durchgesetzt indem sie gemeint haben: "Wir habens jetzt sauberer, durchsichtiger gemacht" und die neuen Beispiele nutzen das nun größtenteils. Ok, ich mag schon übertrieben haben, aber wenn ich Tutorials (die ja von Leuten die lehren wollen geschrieben sind, also nicht ganz Anfänger sind) lese, die zu Stern-Imports raten, dann werd ich immer grantig.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
lunar

Leonidas hat geschrieben:
lunar hat geschrieben:Fändest du das denn bequemer, wenn das Q nicht da wäre?
Wenns qt.Application wäre - ja, durchchaus. Würdest du denn gerne logging.LStreamHandler und logging.LSocketHandler haben?
Wäre es so, würde es mich wenig stören. Sie nachträglich einzuführen, ist natürlich ausgewachsener Schwachsinn. Wegen einem einzigen Buchstaben eine Aufstand zu machen, ist leicht übertrieben,
lunar hat geschrieben:
Für die Python-Bindings hätten die da ruhig aufräumen können
Zu welchen Zweck? Damit alle immer erstmal Suchen-Und-Ersetzen drüber laufen lassen müssen, wenn sie C++-Code auf Python portieren? Damit C++-Programmierer sich schlechter mit Python-Programmieren unterhalten können?
Das ist doch quatsch. An den Namen wirds am wenigsten scheitern. Eher werden sich die C++-Leute wundern was denn diese Properties oder Duck Typing sind.
Das ist kein Quatsch. Im kommerziellen Bereich nutzen viele Programmierer PyQt4 für Prototypen, weil man damit schnell lauffähige GUIs erzeugen und damit das Marketing überzeugen kann ;)
APIs ungeändert übernehmen ist zwar einfach, aber du stimmst mir doch sicher zu, dass die aus anderen Sprachen übernommenen APIs von Minidom, Logging und pywin32 alles andere als komfortabel sind
Ich habe von all diesen APIs nur Logging benutzt. Das ist zwar unkomfortabel, aber doch keine Katastrophe.
lunar hat geschrieben:Und ehrlich gesagt, ich empfinde das Q-Präfix nicht als "unordentlich", also sehe ich auch keinen Grund, dort "aufzuräumen".
Unordentlich nicht, aber schlichtweg unnötig. Es bringt keinen Verständnisgewinn. Ungarische Notation war in VB mal in :)
Es bringt keine Verständnisgewinn, es erschwert das Verständnis aber auch nicht, noch macht es den Code schwerer lesbar. Außerdem ist das keine Ungarische Notation.
lunar hat geschrieben:Ach? Qt3 hat "qt" als Modul-Namen genutzt, was die Leute nicht davon abgehalten hat, trotzdem Sternchen-Imports zu verwenden. Ebenso glaube ich nicht, dass "from wx import *" bei Anfängern nicht verbreitet ist. Sorry, aber ich denke, du dramatisierst.
Ok, ich mag schon übertrieben haben, aber wenn ich Tutorials (die ja von Leuten die lehren wollen geschrieben sind, also nicht ganz Anfänger sind) lese, die zu Stern-Imports raten, dann werd ich immer grantig.
Diese Tutorial sind sicherlich Mist, aber du kannst es der Bibliothek nicht vorwerfen, wenn Autoren sich nicht an die offizielle Doku halten. Wäre das ein Tutorial über wx gewesen, würden wir diese Diskussion nicht über die Bibliothek, sondern über das schlechte Tutorial führen. Du bist da leicht voreingenommen.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

lunar hat geschrieben:Das ist kein Quatsch. Im kommerziellen Bereich nutzen viele Programmierer PyQt4 für Prototypen, weil man damit schnell lauffähige GUIs erzeugen und damit das Marketing überzeugen kann ;)
Naja, und wegen dem fehlenden, in Python überflüssigen Q ist das nicht mehr möglich?
lunar hat geschrieben:Ich habe von all diesen APIs nur Logging benutzt. Das ist zwar unkomfortabel, aber doch keine Katastrophe.
So schlimm wie pywin32 ist PyQt ja nicht, das will ich auch damit nicht sagen, nur geht es mir darum, dass APIs übernehmen nur Programmierern anderer Sprachen hilft, Python-Programmierer aber öfter stört.
lunar hat geschrieben:Es bringt keine Verständnisgewinn, es erschwert das Verständnis aber auch nicht, noch macht es den Code schwerer lesbar. Außerdem ist das keine Ungarische Notation.
Leichter aber auch nicht, also ist es so ziemlich unnütz.
lunar hat geschrieben:Diese Tutorial sind sicherlich Mist, aber du kannst es der Bibliothek nicht vorwerfen, wenn Autoren sich nicht an die offizielle Doku halten. Wäre das ein Tutorial über wx gewesen, würden wir diese Diskussion nicht über die Bibliothek, sondern über das schlechte Tutorial führen. Du bist da leicht voreingenommen.
Ich kann der Bibliothek vorwerfen, dass sie zu einem schludrigen Stil verleitet. Genauso wie ich PHP vorwerfen kann, dass Sparache zu unstrukturierter Programmierung verleitet. Natürlich, man kann es in beiden Fällen auch anders machen. wx hat dies ja auch gemacht und sehe ich inzwischen durchaus als Kritikpunkt (damals, als das noch so war noch nicht, da ich das nicht sonderlich verstanden habe).

Natürlich, PyQt ist da logischerweise nicht allein schuldig, aber so ganz unschuldig ist es an der Situation ja nicht.

Hach, was kann man sich gut über ein Q streiten :D
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
burli
User
Beiträge: 1156
Registriert: Dienstag 9. März 2004, 18:22

Hm, ich habe in Erinnerung das mal irgendwo geschrieben wurde Python würde häufig dazu verwendet um "mal eben auf die Schnelle" eine Applikation zu entwickeln um sie dann später in C++ zu übertragen. Den Sinn hab ich zwar nicht verstanden, aber so wurde es beschrieben. Vielleicht hängen viele noch an dem Glauben Python sei eine Prä-C++ Sprache.


@Leonidas, machen wir es doch mal kurz: wie sieht denn die korrekte Anwendung von PyQt aus so wie es jetzt angeboten wird und wie sollte es Deiner Meinung nach aussehen und warum? Vielleicht wird ja so Dein Standpunkt deutlicher
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

burli hat geschrieben:Hm, ich habe in Erinnerung das mal irgendwo geschrieben wurde Python würde häufig dazu verwendet um "mal eben auf die Schnelle" eine Applikation zu entwickeln um sie dann später in C++ zu übertragen. Den Sinn hab ich zwar nicht verstanden, aber so wurde es beschrieben. Vielleicht hängen viele noch an dem Glauben Python sei eine Prä-C++ Sprache.
Das hat mit Prototyping recht wenig am Hut. Prototyping ist dazu da, dass man mit Python schnell einen mehr oder minder funktionsfähigen Prototyp basteln kann, den man nutzen kann um die Realisierbarkeit zu testen oder um den Chef zu überzeugen. Dann kann man es in C++ neu schreiben, weil man sich gerne selbst quält (*g*) oder weil der Chef das so verlangt.
burli hat geschrieben:@Leonidas, machen wir es doch mal kurz: wie sieht denn die korrekte Anwendung von PyQt aus so wie es jetzt angeboten wird und wie sollte es Deiner Meinung nach aussehen und warum? Vielleicht wird ja so Dein Standpunkt deutlicher
Aktuell:

Code: Alles auswählen

import QtGui
PyQt4.QtGui.QApplication
Aktuelles Problem:

Code: Alles auswählen

from PyQt4.QtGui import *
QApplication
IMHO besser:

Code: Alles auswählen

import qt
qt.Application
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
burli
User
Beiträge: 1156
Registriert: Dienstag 9. März 2004, 18:22

Ok, aber wo ist das Problem von "from xyz import *"?

Rein technisch kann es doch nur Probleme geben wenn man zwei Namensräume importiert die Methoden mit identischen Namen haben.

Alles andere ist doch eigentlich nur eine Konvention der Python Programmierer zur Vereinheitlichung von Code, oder hab ich was missverstanden?

Ich will mich nicht beschweren, nur verstehen und lernen

Es gibt im übrigen noch eine Variante die mir persönlich am besten Zusagt und in den Examples von python_qt_doc verwendet wird

Code: Alles auswählen

import sys
from PyQt4 import QtCore, QtGui

app = QtGui.QApplication(sys.argv)
quit = QtGui.QPushButton("Quit")
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

burli hat geschrieben:Ok, aber wo ist das Problem von "from xyz import *"?
Die von dir bereits erwähnten Namespace-Clashes und außerdem ist der Code schwerer zu verstehen weil man mehrere hunderte Namen in den Modulnamespace bekommt und die nutzen kann. Bei einem erneuten lesen ist es nicht unbedingt klar, wo ein bestimmter Name herkommt. Mit Namespaces hingegen kein Problem.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
BlackJack

@burli: Das "nur" solltest Du aus dem Satz streichen. Früher oder später *kommt* es zu solchen Kollisionen. Beliebte Beispiele, die mehr oder weniger regelmässig nachgefragt werden, sind `Tk.Image` vs. `PIL.Image`, `numpy.random` vs. `random` aus der Standardbibliothek, und `os.open()` vs. `open()`.

Was ebenfalls sehr blöd ist, ist Code der problemlos läuft, bis man eine Bibliothek aktualisiert und *dann* eine Kollision entsteht. Im Grunde hat man mit jedem Sternchen-Import eine tickende Zeitbombe.

Wenn das jeder machen würde käme auch noch dazu, dass sich die Namen dann über viele Module weiter verteilen und bei jedem *-Import mehr werden. Damit holt man sich aus einem Modul ja auch die Namen, die das importierte Modul seinerseits per * importiert hat. Damit wäre letztendlich das gesamte Modul-Konzept hinfällig und man könnte gleich "includes" á la PHP einführen.
lunar

Leonidas hat geschrieben:
lunar hat geschrieben:Das ist kein Quatsch. Im kommerziellen Bereich nutzen viele Programmierer PyQt4 für Prototypen, weil man damit schnell lauffähige GUIs erzeugen und damit das Marketing überzeugen kann ;)
Naja, und wegen dem fehlenden, in Python überflüssigen Q ist das nicht mehr möglich?
Wenn man zwischen verschiedenen Sprachen wechselt, dann sollten die Klassennamen schon gleich sein, und wenn es nur darum geht, dass der Chef sieht, dass der Python-Code auch Qt4 verwendet ;)
lunar hat geschrieben:Ich habe von all diesen APIs nur Logging benutzt. Das ist zwar unkomfortabel, aber doch keine Katastrophe.
So schlimm wie pywin32 ist PyQt ja nicht, das will ich auch damit nicht sagen, nur geht es mir darum, dass APIs übernehmen nur Programmierern anderer Sprachen hilft, Python-Programmierer aber öfter stört.
Sprich für dich, und überlasse anderen, sich ihre Meinung selbst zu bilden. Mich stört das Q nicht, ebenso wenig wie es andere zu stören scheint, denn von einem PyQt4-Programmierer habe ich diese Klagen noch nicht gehört.

Es sagt in gewisser Weise etwas über dich und PyQt4 aus, wenn du dich als Gtk- oder Wx-Programmierer über das Namenspräfix von Qt4 beschwerst...
lunar hat geschrieben:Es bringt keine Verständnisgewinn, es erschwert das Verständnis aber auch nicht, noch macht es den Code schwerer lesbar. Außerdem ist das keine Ungarische Notation.
Leichter aber auch nicht, also ist es so ziemlich unnütz.
Du stimmst mir also zu, dass das Präfix das Verständnis nicht erschwert, und die Lesbarkeit von Code beeinträchtigt. Es bestehen also in der täglichen Arbeit keine messbaren Einschränkungen. Obwohl also keinerlei Nachteil besteht, keinerlei Behinderung auftritt, sollen die Maintainer sich trotzdem die Arbeit machen, alle Präfixe zu entfernen, bei einem Framework, welches bei weitem mehr Klassen hat als Gtk oder Wx?

Bitte, Qt4 ist freie Software, fühle dich also frei, Patches einzureichen. Von den Maintainern kannst du das nicht ernsthaft verlangen, da noch nicht mal irgendein erkennbarer Nutzen aus dieser Maßnahme zu gewinnen ist.

Sorry, aber da gibt es andere Stellen, an denen die Arbeitskraft von Python-Entwicklern wesentlich sinnvoller angelegt ist!
Ich kann der Bibliothek vorwerfen, dass sie zu einem schludrigen Stil verleitet.
Weil das umständliche Präfix angeblich Sternchen-Imports Vorschub leistet?

Qt4 ist - obwohl aus C++ stammend - mit die konsistenteste und strukturierteste Bibliothek, die es für Python gibt. Im Gegensatz zu vielen Adhoc-Modulen, die man so für Python sieht und die als works-for-me-Lösung angefangen haben und später gewachsen sind, hat sich bei Qt4 jemand mal wirklich Gedanken ums Design gemacht, und ist dann auch noch auf eine vernünftige Lösung gekommen.
Da gibt es ganz andere Bibliotheken, die zwar Sternchen-Imports nicht befördern, weil sie nur aus einem einzigen Modul bestehen, dafür aber eine API haben, die der GLib zur Ehre gereicht.
Leonidas hat geschrieben:Dann kann man es in C++ neu schreiben, weil man sich gerne selbst quält (*g*) oder weil der Chef das so verlangt.
In der Realität sind da wohl eher Dinge wie Legacy-C++-Code, gewachsene Bibliotheken, fehlende Inhouse-Entwickler für Python und andere solche Kleinigkeiten.

Mit dem Chef wird man fertig, aber wenn man der einzige Python-Entwickler für ein MLOC-Projekt ist, dann nimmt man doch lieber C++. Da kommt man dann am Ende mit weniger Arbeit raus ;)
Aktuell:

Code: Alles auswählen

import QtGui
PyQt4.QtGui.QApplication
Wie immer du auch darauf gekommen bist, die Doku empfiehlt das nicht! Den offiziellen und vernünftigen Weg kannst du burli's Posting entnehmen. Vielleicht kann man dann ja in Zukunft mal gute PyQt4-Beispiele in deinen Postings lesen ;)
IMHO besser:

Code: Alles auswählen

import qt
qt.Application
Das ist aber nicht zu realisieren. Du versuchst, hier deine Erfahrungen aus Wx und PyGtk auf PyQt4 zu transferieren, was aber nicht funktioniert, da PyQt4 nun mal wesentlich mehr ist als nur ein GUI-Framework. PyQt4 enthält noch wesentlich mehr Klassen u.a. für SVG-Verarbeitung, Netzwerkzugriff und XML-Parsing.

Nun verwendet aber nicht jedes Programm, welches QtGui verwendet, auch QtXml, gerade weil es mit z.B. lxml auch andere XML-Pakete gibt. Deine Lösung würde das gesamte Qt4-Toolkit beim Start laden, selbst wenn man nur an den GUI-Klassen interessiert ist.

Die gegenwärtige Struktur mit dem PyQt4 Paket, welches die einzelnen Qt4-Module bereitstellt, würde von Leuten entworfen, die sich mit Qt4 wesentlich besser auskennen als wir beide zusammen und die für ihre Entscheidung gute Gründe hatten, über die nachzudenken sich lohnt.
Antworten