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
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
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.