Python Bindings for KDE (PyKDE-3.3.16.0)
Prev		Next

General Limitations

Python Strings, Qt Strings and Unicode

Unicode support was added to Qt in v2.0 and to Python in v1.6. In Qt, Unicode +support is implemented using the QString class. It is +important to understand that QStrings, Python string objects +and Python Unicode objects are all different but conversions between them are +automatic in many cases and easy to achieve manually when needed.

Whenever PyKDE expects a QString as a function argument, a +Python string object or a Python Unicode object can be provided instead, and +PyKDE will do the necessary conversion automatically.

You may also manually convert Python string and Unicode objects to +QStrings by using the QString constructor +as demonstrated in the following code fragment.

qs1 = QString('Converted Python string object')
+qs2 = QString(u'Converted Python Unicode object')

In order to convert a QString to a Python string object use +the Python str() function. Applying +str() to a null QString and an empty +QString both result in an empty Python string object.

In order to convert a QString to a Python Unicode object use +the Python unicode() function. Applying +unicode() to a null QString and an empty +QString both result in an empty Python Unicode object.

Access to Protected Member Functions

When an instance of a C++ class is not created from Python it is not possible +to access the protected member functions, or emit the signals, of that +instance. Attempts to do so will raise a Python exception. Also, any Python +methods corresponding to the instance's virtual member functions will never be +called.

Garbage Collection

C++ does not garbage collect unreferenced class instances, whereas Python does. +In the following C++ fragment both colours exist even though the first can no +longer be referenced from within the program:

c = QColor();
+c = QColor();

In the corresponding Python fragment, the first colour is destroyed when +the second is assigned to c:

c = QColor()
+c = QColor()

In Python, each colour must be assigned to different names. Typically this +is done within class definitions, so the code fragment would be something like:

self.c1 = QColor()
+self.c2 = QColor()

Sometimes a Qt class instance will maintain a pointer to another instance and +will eventually call the destructor of that second instance. The most common +example is that a QObject (and any of its sub-classes) keeps +pointers to its children and will automatically call their destructors. In +these cases, the corresponding Python object will also keep a reference to the +corresponding child objects.

So, in the following Python fragment, the first QLabel is +not destroyed when the second is assigned to l because the +parent QWidget still has a reference to it.

p = QWidget()
+l = QLabel('First label',p)
+l = QLabel('Second label',p)

C++ Variables

Access to C++ variables is supported. They are accessed as Python instance +variables. For example:

tab = QTab()
+tab.label = "First Tab"
+tab.r = QRect(10,10,75,30)

Global variables and static class variables are effectively read-only. They +can be assigned to, but the underlying C++ variable will not be changed. This +may change in the future.

Access to protected C++ class variables is not supported. This may change in +the future.

Multiple Inheritance

It is not possible to define a new Python class that sub-classes from more than +one Qt class.

tr() methods

+In a normal Qt installation, every descendant of QObject inherits two methods +(tr (const char *) and tr (const char *, const char *) from QObject explicitly +and also overloads these methods via the moc mechanism (by defining Q_OBJECT +in the class declaration). KDE however is compiled with -DQT_NO_TRANSLATION, +which prevents moc from creating the overloading tr() methods, and also produces +side-effects with a normal Qt installation which was compiled without the +-DQT_NO_TRANSLATION switch. +

+PyKDE handles this situation by NOT providing tr() methods (either the inherited +methods from QObject or the moc generated methods) for any KDE based QObject +descendant. The tr() methods are static, so QObject::tr () methods are available +via PyQt, as are tr() methods for any PyQt QObject descendant. PyKDE's handling +of these methods has no effect on PyQt. +

Instead of the tr() methods, KDE uses corresponding i18n() methods for translating. +These methods are available in the kdecore module of PyKDE. For compatibility with +KDE, you should use the i18n methods. +

Socket classes

+Most of their functionality already exists in the Python socket class or in the +KSocket class (kdecore module). These classes may be implemented at a future date +(they require support for C socket structures and careful handling to avoid buffer +overflow problems/exploits) +

Prev	Home	Next
DCOP and Extensions		Signal and Slot Support