Some background: at FOSDEM, I chatted with Simon Edwards about the utility
of pyQt and pyKDE. I was told "it's stable, easy to use." For experiments
I can certainly see the utility - script up a little wizard, say, or play
with dialog layouts for usability studies/tryouts before setting the code
in stone. For things that might need to be updated more regularly than KDE
releases, but for which you don't want to force a recompile, it would be
ideal. For little administrative apps which are neither IO nor CPU bound,
but just user-bound, pyQt would be usable as well. So, with that in mind,
I've completely ignored it again for the past month.

More background: http://www.cse.unsw.edu.au/~cs3141/ is a course on pyqt /
pykde, announced in kde-devel among other places.
http://mats.imk.fraunhofer.de/pipermail/pykde/2004-March/007349.html is
the start of a thread about deployment of pyKDE.

A recurring question is: how to get py(Qt|KDE) out the door in a timely
manner to correspond to a KDE release [1] and how to get py(Qt|KDE) onto
users' and developers' desktops so that it is usable [2].

Please discuss.

[On a vastly orthogonal sidetrack, I'd for instance be interested in doing
some parts of KPilot in Python, so I can leverage existing Python
libraries for communicating with the Pilot, like Plucker.]


[1] Apparently, pyQt development has become a lot more stable recently,
and _in principle_ it's a matter of re-generating the bindings when a new
release comes out. Since everything's frozen prior to a release, it should
be possible to generate the bindings as well in the freeze period even
before a release. One suggestion is to copy generated bindings into KDE
CVS (on a regular basis?) much like qt-copy.

[2] Including a tarball with KDE releases would be one approach.