Das deutsche Python-Forum

Hallo zusammen,

ich bin gerade auf planet.gnome.org auf PySide gestoßen. Klingt auf den ersten Blick sehr interessant als Alternative zu PyQt.

http://www.pyside.org/news/

Was denkt iht so darüber? Oder hat da jemand schon Erfahrungen gesammelt?

It's inevitable.

Wobei ich ja zugeben muss dass die Webseite schonmal einen super Eindruck macht. Die Frage ist nur, wann sie wegen dem Namen "PySide" abgemahnt werden

Hat birkenfeld nicht gewechselt?

Die Dokus sehen schicker aus, als die von PyQt, aber dieses Gelb is auf dauer ziemlich nervig.

Fuer Python-Entwickler sehen sie auch hilfreicher aus, als die C++-Versatzstuecke von PyQt, der Fokus scheint aber wohl nicht auf einer API zu liegen die mehr pythonic ist.

Sieht aber sehr interessant aus, ich wollte mich sowieso mal mit boost.python beschaeftigen.

Edit: Hier ist uebrigens der Dot KDE Artikel: http://dot.kde.org/2009/08/18/pyside-br ... -qt-python
Nokia scheint da wohl einigermassen dahinterzustehen, koennte spannend werden.

Für diese Anbindung spricht, dass sie "offiziell" von Qt Software zu kommen scheint, und das sie LGPL-lizenziert ist.

Ansonsten aber habe ich so meine Zweifel. Die Python3-Unterstützung hängt an Boost.Python und lässt daher wohl noch auf sich warten, Boost ist nicht das schnellste aller Projekte.

Die Doku ist zwar hübsch, schweigt sich aber (zumindest beim Überfliegen) über manche wichtigen Dinge komplett aus (Signale und Slots, Designer-Unterstützung). Schön dagegen finde ich, dass die Beispiele in Python übersetzt wurden, auch wenn ich persönlich keinen allzu großen Gewinn daraus ziehen kann. Anfängern aber hilft das sicherlich. Allerdings fehlen die umfangreichen Tutorien und Howtos der C++-Dokumentation, um Anfänger vollends glücklich zu machen.

Auch wird zwar behauptet, die Anbindung wäre kompatibel zu PyQt4, faktisch ist sie das aber nicht. Manche Methoden haben aufgrund der Beschränkungen von Boost.Python andere Namen (vlg. "PyQt4.QtCore.QFile.permissions(QString)" und "Pyside.QtCore.QFile.filePermissions(QString)"). Die neue PyQt4-API für Signale und Slots wird anscheinend auch nicht unterstützt, dabei sorgt gerade diese Neuerung dafür, dass sich PyQt4 endlich richtig "pythonisch" anfühlt. Insofern finde ich auch merkwürdig, dass die Roadmap davon spricht, PyQt4-Kompatibilität zu Gunsten "pythonischer" Konstrukte aufzugeben, während das Projekt offenbar noch nicht mal die PyQt4-Features unterstützt, die eine solche pythonische API bereitstellen.

Aber ich bezweifele eh, dass dieses Feature so ohne weiteres implementiert werden könnte. Boost.Python ist ein allgemeiner C++-Wrapper und versteht nichts von Qt-Spezifika wie Signalen und Slots. Nicht zuletzt deswegen verwenden PyQt4 und PyKDE4 ja mit SIP einen eigenen Wrapper.

Die DBus-Anbindung bietet der Doku nach zu urteilen auch keine Qt4-Hauptschleife, sondern verwendet die GLib-Hauptschleife, was voraussetzt, dass Qt4 mit GLib-Unterstützung kompiliert ist (was nicht der Fall sein muss).

Diese Punkte sind mir beim Surfen durch die Dokumentation und die Projektseite so aufgefallen. Der Eindruck mag natürlich falsch sein, denn ausprobiert habe ich das nicht (dafür war mir das Kompilieren auf die Schnelle jetzt zu aufwendig).

Leonidas hat geschrieben:Die Frage ist nur, wann sie wegen dem Namen "PySide" abgemahnt werden ;)

Was spricht denn gegen den Namen? Wer hat daran ältere Rechte?

Stefan

Offenbar kompiliert pyside nicht gegen Boost 1.39, da sich die Signatur der Boost-Python-Tupel geändert hat (das zumindest legt die Fehlermeldung nahe). Da ich den Fehler auf die Schnelle nicht korrigieren kann und mein System Boost 1.38 nicht anbietet, hat sich das Ausprobieren damit erledigt. Gibt es denn jemand anderen, der es geschafft hat, pyside zu kompilieren?

lunar hat geschrieben:Gibt es denn jemand anderen, der es geschafft hat, pyside zu kompilieren?

Ich habe es noch nicht probiert. Da ich am WE leider nicht da bin, wird's aber sicherlich erst mal nächste Woche was werden...

lunar hat geschrieben:Offenbar kompiliert pyside nicht gegen Boost 1.39, da sich die Signatur der Boost-Python-Tupel geändert hat (das zumindest legt die Fehlermeldung nahe). Da ich den Fehler auf die Schnelle nicht korrigieren kann und mein System Boost 1.38 nicht anbietet, hat sich das Ausprobieren damit erledigt. Gibt es denn jemand anderen, der es geschafft hat, pyside zu kompilieren?

Wie ich die pyside-Seite verstanden habe, haben sie 1.38 verwendet + Patches aus SVN, so dass ich dachte dass das dann 1.39 entsprechen würde. Bei meinen Versuchen das zu kompilieren ist es genau an dem gleichen Problem gescheitert wie bei dir.

Hat sich da nochmal jemand drum gekümmert?
Ist das Projekt zu gebrauchen?

Ich benötige nämlich einen C++-Python-Wrapper, der zuverlässig mit Qt-Signalen umgehen kann.
Das SIP ist mir zu hakelig.

Ich hab es noch nicht versucht, aber wenn es Probleme mit 1.39 gibt, hab ich auch ausgesch...üsselt.
Was ich gelesen hab soll dank templates der Speicherverbrauch exorbitant sein

Ansonsten möchte ich das hier mal einwerfen:
http://www.kdedevelopers.org/node/4079
Qt-Python-Bindings mit smoke. Und auch QtScript. Läuft performanter und braucht weniger Speicher

Irgendwie hast Du da mehr rausgelesen als drin steht. Über Python-Bindings auf Smoke-Basis sagt der Artikel eigentlich nur, dass sie möglich und wahrscheinlich performant und klein wären. In der Hauptsache geht es aber um QtScript-Bindings, also um Skripting von Anwendungen, nicht um die Entwicklung eigenständiger Anwendungen. QtScript ist kein Binding-Generator, für Python-Programmierer ist das also erstmal ohne Belang. Von solchen QtScript-Bindings profitieren Projekte wie Amarok, in denen die Anwendung über Javascript-Plugins erweitert wird.

Über Python-Bindings auf Smoke-Basis sagt der Artikel nur, dass sie möglich wären. Eine PoC-Implementierung wird zumindest nicht erwähnt, so dass man die Qualität und Funktionalität nicht beurteilen kann.

Natürlich ist letztlich alles besser als boost.python, aber mehr als verhaltenen Optimismus möchte ich mir nicht erlauben

Nachtrag: Ausprobieren kann man PySide so oder so nicht. Selbst wenn es kompilieren würde, funktioniert es mit Python 2.6.3 nicht. Offenbar wurde etwas an der Docstring-Implementierung geändert, Boost.Python-Bindings jedenfalls werfen bei Python 2.6.3 einen AttributeError beim Import.

lunar hat geschrieben:Irgendwie hast Du da mehr rausgelesen als drin steht.

Stimmt

and even suggested that I set up an experimental PySide clone of a PySmoke binding in their gitorious project.

hab das "suggested" überlesen und interpretiert, dass er schon eines hat... :/

Über Python-Bindings auf Smoke-Basis sagt der Artikel eigentlich nur, dass sie möglich und wahrscheinlich performant und klein wären. In der Hauptsache geht es aber um QtScript-Bindings, also um Skripting von Anwendungen, nicht um die Entwicklung eigenständiger Anwendungen. QtScript ist kein Binding-Generator, für Python-Programmierer ist das also erstmal ohne Belang. Von solchen QtScript-Bindings profitieren Projekte wie Amarok, in denen die Anwendung über Javascript-Plugins erweitert wird.

Das ist mir auch klar. War in meiner Ausführung etwas kurz. Wollte sagen "PyQt-Implemetierung mit smoke, ebenso QtScript-Implementierung mit Smoke".
Für Python-Programierer ist QtScript sowieso dermaßen uninteressant, da Python selber schon eine Scriptsprache ist. Und noch nen zweiten Interpreter laufen lassen ist doof.

In jedem Fall sind 2 (Mann-Arbeits-)Wochen für das QtScript-Zeugs recht wenig (gut, ist noch lange nicht fertig...), und ich bin mir sicher bei dem Peil den rdale von der Materie hat, wird man bald mehr von dem Projekt hören.

hat inzwischen jemand mal ausführlicher Pyside getestet? Gibt ja wohl inzwischen zumindest fertige Pakete für Ubuntu 9.10

So ich antworte mir mal selbst. Offensichtlich ist gerade eine Umstellung von Boost.Python auf etwas namens Shiboken. Ein Teil der Beispiele funktioniert, soweit ich getestet habe. Ein paar Beispiele funktionieren allerdings nicht. Teilweise stürzen die Programme mit SegFaults ab.

Pluspunkte für PySide ist die Pythonischere API und die Doku in Python. Die eins zu eins Kopie von PyQt fand ich nie besonders toll

Die „pythonischere“ API?! Kannst Du das mal näher erläutern?

Nicht wirklich. Stand irgendwo. Aber so wie es aussieht ist die API zu PyQt identisch. Sehe jedenfalls keine Unterschiede.

Jedenfalls scheint es noch nicht zu gebrauchen zu sein.

„Stand irgendwo“ ist keine berauschende Quelle. Wahrscheinlich beziehst Du Dich auf den Abschnitt der Roadmap.

PyQt4 aber hat in dieser Hinsicht viele Verbesserungen erfahren. Signale sind mittlerweile als Deskriptoren implementiert, so dass C++-Signaturen nicht mehr nötig sind. QString und QVariant werden nun (optional) transparent in entsprechende Python-Objekte umgesetzt. Gerade bei QVariant, der aufgrund der dynamischen Typisierung in Python eigentlich völlig überflüssig ist, ist das eine echte Erleichterung.

Insofern hat wahrscheinlich PyQt4 zur Zeit die pythonischere API, und die Ankündigung der Roadmap sind – zumindest in nächster Zeit – eher Makulatur.

Was die Dokumentation angeht, so ist eine nach Python übersetzte Klassenreferenz zwar nett, aber meines Erachtens nach nicht das wichtigste. Die ganzen Tutorien und Grundlagen-Artikel der Qt-Dokumentation fehlen eben so wie eine Darstellung aller Python-Spezifika nach Art des PyQt4 Reference Guide. Das ist mir persönlich viel wichtiger als eine Python-Klassenreferenz.

Ja, dass hab ich wohl gelesen.

Jedenfalls scheint die API weitestgehend identisch zu sein. Ich habe einige PySide Beispiele einfach umgeändert, so das statt PySide eben PyQt4 verwendet wird. Das MDI Beispiel funktioniert mit PyQt z.B. besser. Bei PySide funktionieren die Funktionen wie Tile und Cascade nicht