Ergebnis 1 bis 20 von 385

Thema: IM IN YR LOOP\n VISIBLE FOO\n IM OUTTA YR LOOP - Der Programmierer-Spamthread #2

Baum-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #11
    In erster Linie natürlich nichts, außer vielleicht im Vergleich zu PyQt, das keine LGPL-Lizenz anbietet, oder im Vergleich zu PySide, das laut der offiziellen Website noch keinen Windowsport besitzt.

    Ehrlich gesagt habe ich mit keinem der Kandidaten Erfahrungen gesammelt und meine Python-Zeiten sind schon etwas länger her, so dass ich nicht mehr auf dem aktuellen Stand bin. Aus diesem Grund zitiere ich hier lieber die, die sich mehr auskennen:

    Zitat Zitat von http://doc.trolltech.com/qq/qq23-pythonqt.html#aboutpythonqt
    Unlike PyQt and Qt Jambi, PythonQt is not designed to provide support for developers writing standalone applications. Instead, it provides facilities to embed a Python interpreter and focuses on making it easy to expose parts of the application to Python.

    PythonQt makes extensive use of the Qt 4 meta-object system. Thus, PythonQt can dynamically script any QObject without any prior knowledge of it, using only the information supplied by QMetaObject (defined using Qt's moc tool in C++ applications). This dynamic approach allows several different script bindings to be embedded in the same application, each of which can use the same scripting API; e.g., JavaScript (QSA or QtScript) and Python.
    Zitat Zitat von http://pythonqt.sourceforge.net/Features.html
    Comparison with PyQt/PySide

    PythonQt is not as pythonic as PyQt in many details (e.g. buffer protocol, pickling, translation support, ...) and it is mainly thought for embedding and intercommunication between Qt/Cpp and Python
    PythonQt allows to communicate in both directions, e.g., calling a Python object from C++ AND calling a C++ method from Python, while PyQt only handles the Python->C++ direction
    PythonQt offers properties as Python attributes, while PyQt offers them as setter/getter methods (e.g. QWidget.width is a property in PythonQt and a method in PyQt)
    PythonQt currently does not support instanceof checks for Qt classes, except for the exact match and derived Python classes
    QObject.emit to emit Qt signals from Python is not yet implemented but PythonQt allows to just emit a signal by calling it like a normal slot
    PythonQt does not (yet) offer to add new signals to Python/C++ objects and it does not yet support the newstyle PyQt signals (so you need to connect via C++ string signatures)
    Ownership of objects is a bit different in PythonQt, currently Python classes derived from a C++ class need to be manually referenced in Python to not get deleted too early (this will be fixed in a future version)
    QStrings are always converted to unicode Python objects, QByteArray always stays a QByteArray and can be converted using str()
    There are many details in the generated wrappers that could need some polishing, e.g., methods that use pointer arguments for additional return values could return a results tuple.
    Not all types of QList/QVector/QHash templates are supported, some Qt methods use those as arguments/return values (but you can add your own handlers to handle them if you need them).
    Probably there are lots of details that differ, I do not know PyQt that well to list them all.
    In the long run, PythonQt will consider using/extending PySide with the features of PythonQt to get rid of its own generator and typesystem files, alternatively the KDE Smoke generator might be used in the future (this has not yet been decided, the current PythonQt generator works well and there is no hurry to switch).
    BTW: So viel attraktiver wird PySide dadurch, dass es von einem Nokia-Tochterunternehmen entwickelt wird auch nicht. Zumindest macht MeVis ebenfalls was her.


    Was Psyco angeht, kann es auf der einen Seite natürlich ein Problem darstellen, dass es nicht mehr weiterentwickelt wird, muss auf der anderen Seite aber nicht. Wie gesagt, wenn mehr Performance benötigt wird, kann man damit experimentieren.

    Je nach Situation, kann eine Verbesserung der Rechenleistung durchaus etwas bringen, besonders in Spielen.

    Außer Psyco kenne ich noch Unladen Swallow, aber das ist scheinbar 2009 auch ins Stocken geraten.

    In jedem Fall ist es immernoch möglich performancekritischen Code nach C/C++ auszulagern. Das ist eigentlich auch eine bewährte Vorgehensweise.

    Geändert von Kyuu (18.08.2010 um 16:06 Uhr)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •