PythonQt
http://pythonqt.sourceforge.net/index.html
Introduction
PythonQt is a dynamic Python binding for the Qt framework. It offers an easy way to embed the Python scripting language into your C++ Qt applications. It makes heavy use of the QMetaObject system and thus requires Qt 4.x.
The focus of PythonQt is on embedding Python into an existing C++ application, not on writing the whole application completely in Python. If you want to write your whole application in Python, you should use PyQt or PySide instead.
If you are looking for a simple way to embed Python objects into your C++/Qt Application and to script parts of your application via Python, PythonQt is the way to go!
PythonQt is a stable library that was developed to make the Image Processing and Visualization platform MeVisLab scriptable from Python.
Built-in Features
The following are the built-in features of the PythonQt library:
- Access all slots, properties, children and registered enums of any QObject derived class from Python
- Connecting Qt Signals to Python functions (both from within Python and from C++)
- Easy wrapping of Python objects from C++ with smart, reference-counting PythonQtObjectPtr.
- Convenient conversions to/from QVariant for PythonQtObjectPtr.
- Wrapping of C++ objects (which are not derived from QObject) via PythonQtCppWrapperFactory
- Extending C++ and QObject derived classes with additional slots, static methods and constructors (see Decorators)
- StdOut/Err redirection to Qt signals instead of cout
- Interface for creating your own
importreplacement, so that Python scripts can be e.g. signed/verified before they are executed (PythonQtImportFileInterface) - Mapping of plain-old-datatypes and ALL QVariant types to and from Python
- Support for wrapping of user QVariant types which are registerd via QMetaType
- Support for Qt namespace (with all enumerators)
- All PythonQt wrapped objects support the dir() statement, so that you can see easily which attributes a QObject, CPP object or QVariant has
- No preprocessing/wrapping tool needs to be started, PythonQt can script any QObject without prior knowledge about it (except for the MetaObject information from the moc)
- Multiple inheritance for C++ objects (e.g. a QWidget is derived from QObject and QPaintDevice, PythonQt will automatically cast a QWidget to a QPaintDevice when needed)
- Polymorphic downcasting (if e.g. PythonQt sees a QEvent, it can downcast it depending on the type(), so the Python e.g. sees a QPaintEvent instead of a plain QEvent)
- Deriving C++ objects from Python and overwriting virtual method with a Python implementation (requires usage of wrapper generator or manual work!)
- Extensible handler for Python/C++ conversion of complex types, e.g. mapping of QVector<SomeObject> to/from a Python array
- Setting of dynamic QObject properties via setProperty(), dynamic properties can be accessed for reading and writing like normal Python attributes (but creating a new property needs to be done with setProperty(), to distinguish from normal Python attributes)
Features with wrapper generator
Thanks to the new wrapper generator, PythonQt now offers the additional PythonQt_QtAll library which wraps the complete Qt API, including all C++ classes and all non-slots on QObject derived classes. This offers the following features:
- Complete Qt API wrapped and accessible
- The following modules are available as submodules of the PythonQt module:
- QtCore
- QtGui
- QtNetwork
- QtOpenGL
- QtSql
- QtSvg
- QtUiTools
- QtWebKit
- QtXml
- (QtXmlPatterns, QtScript, QtHelp, phonon, assistant, designer are currently not supported, this would require some additional effort on the code generator)
- For convenience, all classes are also available in the PythonQt.Qt module, for people who do not care in which module a class is located
- Any Qt class that has virtual methods can be easily derived from Python and the virtual methods can be reimplemented in Python (this feature is considered experimental!)
- Polymorphic downcasting on QEvent, QGraphicsItem, QStyleOption, ...
- Multiple inheritance support (e.g., QGraphicsTextItem is a QObject AND a QGraphicsItem, PythonQt will handle this well)
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).