PyKDE API Forges Ahead with Plugin Support

The latest release of PyKDE (3.8.0) includes the ability to write KDE panel applets completely in Python -- absolutely no C++ required. This is the first in what's planned to be a number of extensions for PyKDE that allow plugins and related objects to be created entirely in Python; David Boddie is nearing release of modules for authoring KParts for export (PyKDE already imports KParts), KDE Control Center modules, and IOSlaves.

Future plans include allowing QWidget subclasses created in Python to be imported into Qt Designer with complete functionality, and possibly Python scripting and plugins for KDE apps like KOffice and Kontact. The underlying mechanisms and code are similar in all cases.

In some cases, specific .so libs will still be required (depends on the plugin loader), but the Python modules will include autogeneration of the necessary C++ code, along with installers to simplify the task of making the plugins available.

PyKDE 3.8.0 requires SIP 3.8 and PyQt 3.8. While the PyKDE 3.8.0 tarball is available now, it will be several days or more before RPM and Debian packages are available. You can check the PyKDE mailing list for more info.


Jim and David, this is terribly impressive stuff!

PyKDE is becoming an awesome desktop scripting platform and simply makes the KDE development platform as a whole that much more compelling -- and a beast to reckon with.

By Navindra Umanee at Thu, 2003/11/06 - 6:00am

If only the Perl/KDE bindings would materialize...

By Stunji at Thu, 2003/11/06 - 6:00am

Why not give the Python bindings a go? :)

By Richard Jones at Thu, 2003/11/06 - 6:00am

The PerlQt bindings use a library called 'Smoke', which has been Qt-only until recently. But I've got it working with the KDE classes now, and so it shouldn't be too long before Perl/KDE bindings are done. You'll have to ask Germain Garand of the PerlQt team - he's certainly got a Perl KDE hello world working at least.

The QtRuby bindings are also coming along well (they use Smoke too), and I hope there will be a KDE extension for ruby programming soon.

-- Richard

By Richard Dale at Fri, 2003/11/07 - 6:00am

PyQt has always rocked (I've used it for a number of years now) in the way it seamlessly brings Qt's object-oriented structure into Python's object-oriented elegence. The first time I extended QListViewItem in plain Python code to override the paintCell method ... that was eye-opening :) David Goodger is a frickin' genius :)

And now there's PyKDE plugins too. Whee! Jim Bublitz is a frickin' genius :)

I'm only a little disappointed that PyKDE isn't bundled with KDE itself, allowing others to have this kinda power at their fingertips in a stock-standard KDE install.

By Richard Jones at Thu, 2003/11/06 - 6:00am

I agree 100%. KDE needs a scripting alternative, and it should be available, documented and maintained like the regular KDE libraries are. If not, people can use it to scratch their own itches, but it will not have any major impact on the KDE community.

By Claes at Thu, 2003/11/06 - 6:00am

I couldn't agree more. See this recent thread, here at the dot:


By MandrakeUser at Thu, 2003/11/06 - 6:00am

I'll try to keep this short. I'm in favor in principle of PyKDE being more tightly integrated with KDE. In practice it isn't likely. I wouldn't mind a fork, but that also isn't likely to change much wrt KDE inclusion.

First off, PyKDE depends on sip and PyQt written by Phil Thompson. I can't speak for Phil, but we have discussed this and it's extremely unlikely that sip and PyQt will end up in KDE CVS, and for what I think are very good reasons. So just putting PyKDE in KDE's CVS wouldn't help a lot (other than Phil's releases are probably more timely than mine).

Second, PyKDE isn't written - it's generated. That by itself makes CVS fairly useless. Third, PyKDE is at the end of the food chain - it can't be generated until KDE and sip/PyQt are done (sip is going from 3->4 and KDE 3.1->3.2 right now, and neither is done). Either sip4 will have bugs (as far as PyKDE is concerned - quite different from PyQt) or (more likely) I'll need to learn sip4, so there's some definite pain coming in that area.

The code ("presip") that generates PyKDE from h files will be released as its own project in 6 months or so. It's not KDE specific, so it doesn't belong in KDE CVS either. It's 100% Python.

There are also a lot of platform-specific problems in building PyKDE on various platforms. There is an excellent Debian maintainer who has made fantastic contributions to PyQt/PyKDE (hi, Ricardo), FreeBSD maintainers have come and gone.I test on SuSE, RH and Mdk, and given an average of 1hr/compile, that takes time (even with multiple boxes) and it takes time to do all the set up for those.

Lastly, I have a lot of time to work on this (and it takes a lot of time), but I can't guarantee to match KDE release schedules. There are times when I have to concentrate on earning money and that sometimes pushes things out several weeks or more.

Fortunately some people like David Boddie and a few others have jumped in and picked up some things like the plugin stuff and done a better job than I would have besides. I've had a basic understanding of how to do that for quite a while, but just haven't found the time to get to it (I had a KSpread plugin cobbled up long ago but the API has changed a lot since then).

These aren't the only considerations - there are things like politics that concern me rightly or wrongly and other stuff I can't think of at the moment. I'd be happy to discuss this with anyone, and I'm not easily offended.

I don't know if all that helps any. If someone else wants to try and integrate this better with KDE, I wouldn't be offended and I'll even throw in the tools (GPL)and assistance. Otherwise, I'll just continue with the best effort I can to keep this up to date with KDE. I may not always be timely, but I've been at this over 2 1/2 years, so I think I can be counted on to get PyKDE out eventually.


By Jim Bublitz at Fri, 2003/11/07 - 6:00am

Hi Jim,

I understand your concerns, but most of these issuses are just practical ones, and should be solvable in one way or the other. If the current process is not a good fit for PyKDE, then perhaps the current process should be changed so that PyKDE can be part of a standard release. What is in CVS and what is not, and the exact date for a release to appear are minor issues in the overall picture.

I am of the opinion that KDE is pretty full-featured as it is, and it should shift focus from adding features and configuration options to programs, and instead improve, optimize and stabilize its frameworks. Adding bindnings so that scripting languages can be tightly integrated and part of the release should be a major issue. If people in control of the KDE release process made a commitment in this direction, I think you would get a lot of help. In my opinion, bindings for Python is more important than SVG support, for example.

By Claes at Fri, 2003/11/07 - 6:00am

You and I are in almost complete agreement. The last time I approached "KDE" about this, the response was generally "sure, if you put it in our CVS". Admittedly this was quite a while ago, and the situation for both KDE and PyKDE was quite different (and I haven't pursued this lately - perhaps it's time for another try).

PyKDE could work as a "loosely coupled" part of KDE - maintaining some degree of independence and handling the release schedule similar to the way KDevelop and KOffice do now. I'd like it to be easy for people to obtain, install and use PyKDE, but not be a general requirement.

This isn't just an "I want to use a different language" situation either - as Roberto pointed out in another post here, you can do things easily in Python that are hard in C++. When I had a plugin running for KSpread, I could do things like run multiple spreadsheet files or even manipulate spreadsheets in the background and have everything communicate, all from a single very small script. I don't believe KSpread does those things yet, at least not easily. Eventually I'd like to get back to that kind of thing, but the KOffice API has been a moving target the last year or so (as it should have been - that's not a complaint), and there's other infrastructure on my side that needs some completion.

This also isn't just a Python issue either - all of the other languages that KDE-Bindings is supporting can benefit from this too.

One of PyKDE's "desgin goals" is also to be completely "non-invasive" wrt KDE - PyKDE doesn't require any special hooks or mods to KDE, or require KDE dependencies on Python or other stuff, and I don't want it to. That, of course, is why plugin support from the PyKDE side is so interesting.

I think what I might do is put together a long explanation of the situation from my perspective and then post some pointers to it on some of the KDE lists.


By Jim Bublitz at Fri, 2003/11/07 - 6:00am

Dear Jim

Thanks a lot for the comments, and for maintaining PyKDE of course :-)

To me, the difference between incorporating PyKDE with the KDE releases and releasing separately, is just enormous. In the former case, one could allow for regular KDE applications (released as a part of KDE) to be written with PyKDE. In the latter case, well not. In a practical sense, integration with KDE would be extremely fruitful for the bindings and for KDE.

Of the reasons you point out, the most serious is the dependence on PyQt, and the fact that PyQt doesn't seem to be going to be included in CVS, ever. In the end, this is really bad.

As for waiting for KDE to stabilize before building the next pykde bindings. This is relative. There is also this issue for the rest of the KDE framework, with repespect to the kdelibs and pyqt. But they work it out. But for each release there is a feature commit freeze well in advance. In fact, you only need the kdelibs to freeze to build PyKDE. ANd I am sure they are pretty reasonable on this regard.

The only way I really see this happen is if a couple of KDElibs core devs commit to the python bindings, and then they coordinate things with you and Phil to ensure that the chain:

Qt --> kdelibs -| --> PyKDE
| --> PyQt ----|

Can be built in time. Volunteers may help test/debug.

The differences between distros/Unix flavors might be solvable using an appropriate build framework, am I wrong ? The files locations are decided at compile time with appropriate configure options for the KDE packages. couldn't these options be used to build PyQT and PyKDE in a generic way ? That's where I would like to see assistance from KDE core devs.

As for the use of CVS, isn't it true that a core part of PyKDE only changes slightly from release to release ? Even if most of the bindings will be generated by sip, if the process is automated to a large extent, maybe one could build a generic snapshot every once in a while, cointaining a PyKDE binding that is current and "mostly works" with KDE CVS. Once the KDElibs are frozen, the process would converge rapidly to a stable binding. The key here is to which extent the bindings can be automated.

Once again, I am all for integrating your work and Phil's work with KDE, not at all in favor of a fork. PyQT and PyKDE exist thanks to you guys (and your respective teams). I am throughing these ideas almost as a proposal to see if they generate any interest in the KDE side and in your side. I hope I had time to commit to this project, but I could at best give a little help here and there. If there is a move in this direction I'll join the list and see how can I help.

Anyways, cheers and keep up the great work !

By MandrakeUser at Fri, 2003/11/07 - 6:00am

You make a lot of good points and I agree with the general tone of your comments, if not some of the specific details. For example, differences between distributions are one of the biggest problems (or have been - they're a little better lately), but not because of file hierarchies. There's an example on the PyKDE list this morning - kdelibs varies from distribution to distribution. One missing method or change in arguments is enough to break all or most of PyKDE, and those are very time-consuming to find.

There are other differences in PyKDE's build system to cut compile time by 80% (and it can still take 20 min to an hour) and allow a single fileset to support multiple distributions and Qt/KDE/Python versions.

As I mentioned in another post, I should probably lay out the details more clearly and then see what other people's opinions are. I would like to see KDE offer more in the way of scriptability because I think it's an important feature - look at how widely (and easily) VB is used, and it's not as good a language as Python, Perl, Ruby, etc.


By Jim Bublitz at Fri, 2003/11/07 - 6:00am

Hi again Jim,

>There's an example on the PyKDE list this morning - kdelibs varies from >distribution to distribution. One missing method or change in arguments is >enough to break all or most of PyKDE, and those are very time-consuming to >find.

But then again, isn't that the beauty of getting PyKDE in the KDE main trunk ?

The version of PyKDE included there should then compile clean with the "vanilla" kdelibs and PyQt provided by KDE. If then a distro decides to alter the kdelibs, it should be THEIR responsibility to patch PyKDE accordingly, to
rerun sip, or whatever is needed to get PyKDE working with their changes,
or am I missing something important here ?

IMHO, to summarize, including PyKDE in the KDE main trunk, not only would benefit KDE immensily, but would also simplify PyKDE development quite a bit, by giving you just ONE target: the current CVS version of the libs ...

Oh, and I couldn't agree more in what you say in the last paragraph, that's why I am posting these messages instead of doing something otherwise more productive :-)

Cheers !

By MandrakeUser at Fri, 2003/11/07 - 6:00am

Just to clarify the issue about SIP/PyQt and the KDE CVS.

The KDE CVS will never be the master repository for either SIP or PyQt, but there is no problem with the KDE CVS containing a copy of the GPL versions. That can happen today and be done by anybody with write access to the repository.

The only "problem" is that updates will have to be done manually, which actually might be a good thing. Given that PyQt and PyKDE have different release schedules, but PyKDE tends to be very dependent on the PyQt version, then deciding when to update the "official KDE versions" of each should be a considered decision.

It just needs somebody in the KDE project to take responsibility for it.

By Phil Thompson at Fri, 2003/11/07 - 6:00am

Hi Phil

Thanks a lot for the input (and for PyQt). In fact, something similar is done with Qt as far as I know, there is always a copy of the "current" qt in CVS, I think the module is "qtcopy" or something similar.

Terrific, If no KDE dev steps up in this thread I'll see what's best. I might fill a wishlist bug report or something similar

Cheers !

By MandrakeUser at Fri, 2003/11/07 - 6:00am

Same here - I don't mind if someone wants to put PyKDE in KDE-CVS. I just don't have time to maintain that and it really doesn't fit my development process. I spend a lot of time developing the tools that generate PyKDE and relatively little time on PyKDE itself. PyKDE comes out pretty much "all at once" and just needs some tweaking and a little handwritten code, and that part is decreasing quite a bit.

The build systems for both PyQt and PyKDE don't conform to KDE's build system though. It would be possible/simple to write another "make" layer above what's there if that's an issue.


By Jim Bublitz at Fri, 2003/11/07 - 6:00am

Ehem. Got my Davids mixed up. Goodger is responsible for the awesome project.

PyQt is the result of (primarily) Phil Thompson's hard work.

David Boddie is obviously the David I was thinking about here, but I was clearly confused :)

By Richard Jones at Thu, 2003/11/06 - 6:00am

Oh, yeah. I had one of those moments a little ago, too.

I was using a qlistview in a designer form, and wanted to override the class´ methods without inheriting... just assign my function to the instance´s .__class__.method and it worked.

I mean, that just can´t be done in C++, I have no idea how PyQt managed :-)

I am doing all my coding (not that it´s too much) in PyQt and/or PyKDE for a while. Check out for a sample (almost to become beta any day now ;-)

By Roberto Alsina at Fri, 2003/11/07 - 6:00am

So, Roberto, what is it about ? I found no info on sf,
but it must be cool :-)

By MandrakeUser at Fri, 2003/11/07 - 6:00am

Nah, no big stuff, just a RSS aggregator :-)

By Roberto Alsina at Sat, 2003/11/08 - 6:00am

By Richard Jones at Fri, 2003/11/07 - 6:00am

Under what license(s) is PyKDE available. PyQt is GPL/commercial like Qt. Is PyKDE LGPL? Do I have to pay for PyKDE for closed source development?

By Nick at Thu, 2003/11/06 - 6:00am

PyKDE is released under the GPL (not LGPL).

By Jim Bublitz at Fri, 2003/11/07 - 6:00am

OK, first of all: Python for closed source development? Yeah, I know it's possible, but c'mon.

Second of all: you want to write a closed-source app, release it . . . are you charging for it? No? That stinks. Yes? Then why aren't you willing to return the favor? If all these people who want to release closed-source apps but aren't willing to pay for a license would stop and think about it a second, they'd realize how hypocritical they're being.

Plus, if you're charging for your software, but are unwilling to take the risk of paying a licensing fee for Qt, you must not have that great of a product to begin with.

By Shane Simmons at Thu, 2003/11/13 - 6:00am

i'm really looking forward to the pykde kparts export, that would be uber-cool (i really wonder how it will be done too).

it also would be nice if pykde was easier to install (now its rather hard if your distro doesn't come with pykde) so people could start releasing pykde apps..

By ik at Thu, 2003/11/06 - 6:00am

> it also would be nice if pykde was easier to install

There are generally rpms available at They're done by volunteers and they lag the source release by a little bit. The tarball went out today, so I'd expect to see SuSE, RH and Mdk rpms in a week or so (but I have no control over when they actually occur).

There is a Debian maintainer who monitors the PyKDE list (address in the original article) and who makes packages available - I'm not sure if they're a part of "official" Debian or not.

There is at least one gentoo user on the PyKDE list - not sure if gentoo is packaging PyQt/PyKDE or not.

The build/compile is fairly long (30 minutes on an Athlon 1900, closer to an hour or more on an 800MHz PIII). If you have problems building, you can post to the PyKDE list - I usually respond quickly and I'm willing to spend as much time as you are (maybe more :) ) getting it running on your system.

(now its rather hard if your distro doesn't come with pykde)

AFAIK, no distro has PyKDE. They usually have sip and PyQt and are usually a version or two out of data (sometimes not a big deal, sometimes it is).


By Jim Bublitz at Fri, 2003/11/07 - 6:00am

"not sure if gentoo is packaging PyQt/PyKDE or not."

Yup - gentoo does have ebuilds, simple as 'emerge pykde'... installs from
source, deals seamlessly with all dependencies.

scanner root # emerge -puv pykde

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild N ] dev-python/sip-3.8
[ebuild N ] dev-python/qscintilla-1.54
[ebuild N ] dev-python/PyQt-3.8.1
[ebuild N ] dev-python/pykde-3.7.4-r2

By Corey at Fri, 2003/11/07 - 6:00am

The guys also have rpms for PyQt and PyKDE, and they are (almost?) part of Fedora, so I would expect them to be available for "Red Hat" from now on.

By Roberto Alsina at Fri, 2003/11/07 - 6:00am

First: This is really cool! Keep up the good work!

The ability of creating plugins in Python is really awesome.

One point where UNIX-like plataforms are a nighmare is software installation. While I'm used to compile many things from source, most of our potential users are not. (And compiling from source is usually time spending.)

With the new PyKDE, a whole world of possibilities is now open. Python scripts are plataform independent: the same script runs under RedHat, Slackware, FreeBSD, Conectiva... Therefore, we can provide programs and components that will run everywhere, providing the user has KDE and PyKDE installed.

Writing programs and plugins in a distro independent way may just be the killer feature for KDE. Or am I being too optimistic?

By Henrique Pinto at Fri, 2003/11/07 - 6:00am

Ideally, all the compiling would be done by the packagers, leaving users to get on with writing Python applications and plugins. This approach sort of works for Panel Applets because the configuration information passed to the applet launcher can be used to infer the name of the relevant Python module. Unfortunately, this doesn't extend to all sorts of plugins because the mechanism for many of them appears to suit a one-library-per-plugin model.

I would hope that most running KDE systems have compilers and linkers available so, by using GUI tools which automatically build libraries for the end user, hopefully the pain is minimised.

We'll see.

By David Boddie at Fri, 2003/11/07 - 6:00am

You're right about the scripting - anything written in Python for PyKDE would be platform independent within *nix family. The problem, as you also note is that PyKDE binaries aren't available for all platforms.

Normally there are RH rpms (usually at There was a FreeBSD package at one time, but I don't believe it's been maintained. If Conectiva is Debian based, I would expect the Debian packages to work there. I know of at least one Slackware user of PyKDE, but he compiles it for his platform.

Generally, the only thing required to "port" PyKDE to one of the Linux platforms is the correct directory locations of the various files - the code doesn't require any modifications I'm aware of. There have also been individuals porting PyKDE to Solaris and HP, but I haven't seen anything made publicly available for those. PyQt is also working now on OSX (with sip 4) - not sure what would be involved in getting PyKDE operational there or on Linux PPC.

I'd be happy to provide any assistance I can with ports/packages.


By Jim Bublitz at Fri, 2003/11/07 - 6:00am

This seems really great and I am suprised that KDE is not jumping at the opportunity to use this great technology, after all it is under the same license as Qt.

Please check it out:
It seems very interesting, easy, and powerful. It iss a perfect amtch for Qt based applications, such as the KDE desktop, is it now?

Please explain the problems with it if you feela nother way.

By Alex at Fri, 2003/11/07 - 6:00am

Or for full KDE integration:

By Ian Reinhart Geiser at Fri, 2003/11/07 - 6:00am

This looks very good. However, I have a few questions.

1. Why was a completely new project started instead of building on top of QSA? The license seems a big enough reason for most people, but were there technical limitations?

2. Which is better ;p ?

3. Ar ethey compatible, do they use the same scripting language?

By Alex at Fri, 2003/11/07 - 6:00am

1) this was started long before QSA
2) this is better for KDE apps
3) nope

By Ian Reinhart Geiser at Fri, 2003/11/07 - 6:00am

Actually they do use the same language - both are Javascript (ECMA). They're even compatible to a degree, but not 100%.


By Richard Moore at Sun, 2003/11/09 - 6:00am

> 1. Why was a completely new project started instead of building on top of QSA?
> The license seems a big enough reason for most people, but were there
> technical limitations?

You'd have to ask TrollTech why they started a new project :) PyQt and the original PyKDE date back at least 4 years.The current PyKDE is about 2 1/2 years old. Both pre-date QSA.

PyQt and PyKDE are (hopefully) only the tip of the eventual iceberg. The same tools can be used to bind lots of other libs for Python scripting. For example, I've looked at doing bindings for a 3D visualization package for a large US govt lab (turned out to be proprietary software, so I couldn't do it). You can use sip to write bindings for nearly any C/C++ libs and over the next year or so, that will become easier. That means almost anything can be combined with Qt/KDE using PyQt/PyKDE/Python if someone produces the bindings and/or wrappers for the "other" libs.

It's already pretty easy to do, but the learning curve for sip is steep because the docs are pretty sparse. One of my goals is to produce tutorials and tools for making that easier. At the same time, Phil Thompson is putting a lot of effort in to making the next sip version much easier to use (sip is the infrastructure that makes all this stuff possible in the first place).

Another way of saying that is that I'd like Python on KDE & Linux to be as ubiquitous and widely usable as VB is on Windows, and Python is already a much better language than VB.

> 2. Which is better ;p ?

I honestly haven't looked at QSA much, so I don't know if better applies in either direction - it depends on what you want scripting to accomplish. Python is a complete development environment with a PyQt/PyKDE/QtDesigner compatible IDE (eric), an extensive selection of libraries (for example strings, os support, XML,sockets, pdf support in ReportLab, math and plotting support, databases, lots of other stuff), convenient built-in data structures, integers as large as available memory to hold them, introspection and just an all-around nice language to work with. The only thing I use C/C++ for any more is PyKDE. Python development is extremely fast, and for GUI apps, the execution speed is more than sufficient, especially since anything with bindings still runs most of its code in C/C++ anyway.

> 3. Are they compatible, do they use the same scripting language?

Don't know - they're different languages, but I haven't looked at using them together.


By Jim Bublitz at Fri, 2003/11/07 - 6:00am

Jim said it best. But let me emphasize it:

PyQt and PyQt bind an extremely powerfull interpreted OO language, Python with KDE. So, it's not a matter of add some scripting binding, it is a matter of binding PYTHON in particular. There are several reasons why I think Python is THE interpreted language for KDE.

By MandrakeUser at Fri, 2003/11/07 - 6:00am

The way I understand it, QSA can really only be used to control a C++ Qt application -- you cannot write a Qt application from scratch using QSA. I may very well be wrong in this but from a quick scan of the website it appears that way.

PyQt/PyKDE allow you to write a complete Qt or KDE application purely in Python. And Python itself provides a wealth of modules with support for everything from data serialization to HTTP server implementations.

It's really quite nifty ;)

By Gordon Tyler at Fri, 2003/11/07 - 6:00am

Yes, it's going to be rather humorous to one day reimplement the HTTP KPart using Python's urllib :)

By Richard Jones at Fri, 2003/11/07 - 6:00am

Don't think I haven't considered it!

Seriously, I think there are application areas where embedded Python can make development a lot more convenient, at least for prototyping purposes. One such area is text manipulation:

Although I'm sure that Perl coders would contend its superiority over Python in this area.

By David Boddie at Sat, 2003/11/08 - 6:00am

That's awesome! I can just see the potential of a ReStructuredText editing KPart!

BTW, I've *been* a Perl programmer, professionally, and I don't contend its superiority over Python for a second in any area except quick-n-dirty sub-10-line file munging scripts. Even then I've stopped using it for those, but mostly 'cos I've fallen out of practise with Perl.

By Richard Jones at Sat, 2003/11/08 - 6:00am

Actually, I didn't think of doing anything with ReStructuredText until I saw this:

I suppose that there are many similarities between Wiki-style "markup" and ReST. However, I was also interested in the possibility of dynamically changing the links between pages and creating new ones.

I've been experimenting with providing different Python modules for processing the text, so it isn't impossible that a ReST module could be included.

By David Boddie at Sat, 2003/11/08 - 6:00am

I'm a *huge* fan of ReST - I've used it for documenting several projects, including:

... and any documentation I produce for work projects are also done in ReST. Along the way, I've convinced (very easily) several co-workers to go down the same path :)

Given ReST's great design, and internal DOM structure, I should think that a "wysiwyg"-ish structured text editor would be pretty easy. And with PDF and HTML outputs...

By Richard Jones at Sat, 2003/11/08 - 6:00am

It looks like a ReST KPart would indeed be very useful. I noticed Ian Bicking's Wiki code in the Docutils Sandbox:

Do you think that this is a good place to start, or do you think that a wrapper for the HTML Writer would be more appropriate? Maybe we should discuss this via e-mail.

I just hope that a tie-in with Docutils isn't going to lead to widespread confusion over which David is which. ;-)

By David Boddie at Sun, 2003/11/09 - 6:00am

I don't have time to get into such a project right now. The docutils mailing list has been an invaluable resource for me in the past.

Plenty of projects in the past have accessed the HTML writer at various levels. The ReST product for Zope, for example, pulls out just the body so it may be wrapped in a different page.

Oh, and really it's only me that you have to worry about getting Davids confused :)

By Richard Jones at Sun, 2003/11/09 - 6:00am

Well.... if you look at KRsN (URL somewhere above :-) in CVS, you can see a stupid web browser implemented using QTextBrowser, urllib and some little glue :-)

Probably about 100 lines of code.

By Roberto Alsina at Sat, 2003/11/08 - 6:00am

Hey,,... is it slower at all ?

By Mathieu Jobin at Fri, 2003/11/07 - 6:00am

I'm sure it's slower in absolute terms. There's the overhead of a byte code interpreter, the creation of objects in "C++-Space" *and* "Python-Space" (things like QWidgets in Python have "shadow" objects in C++), the need to do lookups to find the binding code, and a bunch of other stuff. HOWEVER, what you write in PyKDE or PyQt is the "I" part of the GUI - the "G" part (drawing, clipping, most of the event handling like computing where the mouse was when clicked) still takes place in C++ - the same C++ code your C++ app would use. To a large extent, you're looking at adding a millisecond (probably less) to the part of the operation (the "U" in GUI) which is already orders of magnitude slower than that.

I've never done any real testing. I'd just say most of the time the speed difference isn't noticeable, and in some of the cases where it is, careful coding can help. In general I think of Python as a "dispatcher" - if you use Python to sort a list (which Python's sort() does in C) it's very fast. If you write the sorting routine itself in Python it's likely to be slower. That's the advantage of writing bindings for a C/C++ lib as opposed to rewriting a lib in Python.


By Jim Bublitz at Fri, 2003/11/07 - 6:00am