[Kde-bindings] Re: [PyKDE] Language Overhead: C++ vs Python

Phil Thompson phil at riverbankcomputing.co.uk
Wed Apr 6 14:13:14 BST 2005

> On Apr 6, 2005 2:24 PM, Phil Thompson <phil at riverbankcomputing.co.uk>
> wrote:
>> From time to time we get commissioned to develop Python bindings for Qt
>> based widget sets. These often come with examples and part of the work
>> is
>> to port those examples to Python. We then end up with C++ and Python
>> implementations with the same structure, the same functionality, and
>> calling the same API. Any difference in the amount of code is purely
>> down
>> to "language overhead".
>> Below is a comparison of the numbers of lines of code for a number of
>> such
>> examples. For the C++ implementations I have excluded all .pro files and
>> all qmake and moc generated files.
>>              C++   Python   Reduction
>> example_1    509     318       38%
>> example_2    871     516       41%
>> example_3    225     132       41%
>> example_4    142      72       49%
>> example_5    615     363       41%
>> example_6     56      46       18%
>> example_7   1445     764       47%
>> example_8    536     312       42%
> Hi Phil,
> These are indeed nice results. But how is the performance of the
> python implemented widgets? I've never done one myself and I wonder if
> there is any visible speed difference.

You've misunderstood - I'm talking about wrappers for C++ implementations
of Qt based widgets, so speed isn't an issue.

> By the way, are there any Python-implemented widgets available on the
> net? There are some nice widgets in KDE (like Date selector), I would
> like to integrate into my application. But I don't want my application
> depend on PyKDE, since I want it to be portable on Unix, Mac OS X and
> Windows.

I have only ever seen one pure Python implementation of a widget - some
sort of dial - but I can't track down a reference to it. PyQt for Qt 2
includes a port of the Qt themes example which seemed fine speed-wise -
only a toy though.

Of course, because Python is dynamic, you can delay decisions as to which
date selector to use until run-time. Implement a generic date selector
that derives from the KDE selector if it is installed or the standard Qt
selector if not. I think this is what the eric3 IDE does.


More information about the PyQt mailing list