AUG
26
2009

Some Comments on PySide

To be honest I'm not all that happy with the current situation. Riverbank Computing, basically Phil Thompson, has done an excellent job developing SIP and PyQt over the last 10 years and providing a Free Software (GPL) version which PyKDE is built on. Phil has also done an excellent job of providing answers to my queries, basically as a free service to KDE and the FOSS community. Having two competing Python bindings for Qt is a waste of resources and is generally disruptive to the community at large. Seeing the future of Riverbank and the good working relationship between it and KDE jeopardised is not something that appeals to me. I am disappointed that no kind of cooperative agreement could be reached between Nokia and Riverbank Computing.

On the technical side, PySide is just starting out and has a long way to go before it is as mature as PyQt and is a viable replacement for it. This is only natural. Bindings development is not easy -- just ask Richard Dale, he's been at it for years. (As a point of interest Nokia could have saved themselves a lot of effort by building on top of Richard's Smoke libraries/tools.) It will be interesting to see how PySide progresses and what happens in Python / Qt community. In the short term at least, PyKDE will continue to be developed on the mature SIP/PyQt.

Comments

Isn't it damaging to your credibility to say you don't want a competing implementation while you are an open source hacker? I mean, they did try to work together (see FAQ). Let the best implementation win. In the end open source is guaranteed to win.


By Thomas Zander at Wed, 08/26/2009 - 21:12

Isn't it damaging to your credibility to say you don't want a competing implementation while you are an open source hacker?

I think the point is that volunteers like Simon are being expected to do a large amount of work because of a licensing spat. This isn't really about better technology. Simon or others will need to duplicate the work already done on PyKDE, so that commercial users don't have to pay license fees to Riverbank Ltd.

Let the best implementation win.

Maybe. As PySide takes up more that twice the memory at runtime at present, compared with PyQt, it doesn't seem to really be in the running yet. On the other hand, I think a python binding based on the Smoke libraries would be very interesting and would have some technical advantages to offer KDE (such as being smaller than PyQt). So perhaps you would prefer three competing implementations?


By Richard Dale at Wed, 08/26/2009 - 21:42

Thomas wrote: Isn't it damaging to your credibility to say you don't want a competing implementation while you are an open source hacker?

I don't think Simon actually said he didn't want a competing implementation, so I hardly think it's fair to put words in his mouth like that.

Richard wrote: On the other hand, I think a python binding based on the Smoke libraries would be very interesting and would have some technical advantages to offer KDE (such as being smaller than PyQt). So perhaps you would prefer three competing implementations?

I can think of two other sets of Python bindings, so there's no shortage of them. Up until now, however, they all occupied different niches.


By davidb at Wed, 08/26/2009 - 21:57

How does time-to-load compare? (I'm guessing its more or less the same once it gets started.) Our QtJambi-generator-based QtScript bindings are really too slow to load (into seconds of time). If PySide is using templates to do code generation, I suppose it might have the same issue. But I remember Ruby Qt bindings could be slow since it had to load a large array of all the Qt functions.

Anyways do you think a Smoke library for QtScript (aka ECMAScript aka JavaScript) is a possibility? If it was more faster and/or more memory efficient then our current QtScript bindings, you would have a very happy customer @ Amarok. :)


By eean at Wed, 08/26/2009 - 23:03

If a shared library is already loaded, and then a second process that uses the shared lib will be able to start up quicker. If all the KDE language bindings are using the same Smoke shared libraries, and they are half the size of competing approaches, then I would say that should improved start up times because they are more likely to be already loaded.

QtRuby does some work preloading all the classes at start up, and I haven't actually measured how long that takes. But it doesn't need to initialize each method in the smoke lib, and so there is no overhead there.

Would QtScript work well with Smoke? I don't see why not becaue the idea of Smoke is very simple; it is just the moc style generated code on a larger scale. As QtScript works well with slots, signal and properties it should also work in a very similar way with method calls on the Smoke lib.


By Richard Dale at Thu, 08/27/2009 - 09:00

> I think the point is that volunteers like Simon are being expected to do a
> large amount of work because of a licensing spat.

The announcements say that their generator would work just fine for external libraries like the KDE libs. So I must miss something as I read that to mean there is no need for a large amount of extra work.
Besides, I don't recall anyone suggesting we throw away pyqt or the kde bindings using them. It still is packaged by most distros, for example. Any such conclusion would be overly pessimistic.

> This isn't really about better technology.

This sounds a bit like jumping to conclusions, I do think I heard complaints about the pyqt stuff before and how they could not be addressed due to this being a side project of the company that makes it. Are you honestly saying they both have the same approach and no technological reasons exist for creating pyside? I don't buy that.


By Thomas Zander at Thu, 08/27/2009 - 06:26

Even if their generator works really well (which is doubtful considering how young it is) it would still leave a lot of manual work to do. Why? Because binding a library the size of KDE is a big task no matter which way you cut it. And that is leaving out the problem of maintaining backwards compatibility with the current bindings.

You are right that no one is saying that PyQt should be thrown away. But if the developer and maintainer of SIP / PyQt is put out of business and can no longer support the GPL SIP/PyQt, then we have a big problem.

The complaints about PyQt have IMO been very minor in nature and are certainly no reason to justify a reimplementation. Furthermore, the complaints have already been mostly addressed in the current snapshots. (Riverbank first aimed to keep PyQt as close to the C++ API as possible to aid porting Python prototypes to C++. It turns out that few people did this anyway, so now they are moving more towards changing the API suit Python tastes.)

And for the record, PyQt is not a side project. It is Riverbank's primary product and source of income and consulting work.


By simon edwards at Thu, 08/27/2009 - 08:33

So I must miss something as I read that to mean there is no need for a large amount of extra work.

The 500 Qt classes require 8000 lines of XML type system files that the PySide generator uses. So if we have a total of 2000 classes for the KDE libs too, that might mean 32000 lines of XML. Do you know anything about the work involved in implementing a Plasma scripting language binding? Well Simon and I do, and we're happy to tell you that we didn't do it in a weekend. Quite a lot could be reused certainly, but I take exception to being told that going from wrapping the the 500 class Qt api to wrapping 1500 extra classes and associated tech "isn't a lot of work".

Richard said: "This isn't really about better technology."

This sounds a bit like jumping to conclusions, I do think I heard complaints about the pyqt stuff before and how they could not be addressed due to this being a side project of the company that makes it. Are you honestly saying they both have the same approach and no technological reasons exist for creating pyside? I don't buy that.

I'm sorry I've been working on various sorts of language bindings for 10 years and I like to think I know what I'm talking about. And I'm telling you that using Boost::Python for a project on the scale of the combined Qt and KDE apis is a bad idea, because the shared library and runtime is too large. Go and measure the runtime compared with C++ and PyQt like Simon has. Review the PySide code like I have. Other than that, you're welcome to ignore experts in the field if you want, to and accuse us of 'jumping to conclusions', as though we're beginners without much clue.


By Richard Dale at Thu, 08/27/2009 - 08:46

>I think the point is that volunteers like Simon are being expected to do a large amount of work because of a licensing spat. This isn't really about better technology.

This has happened before though. A licensing spat is what resulted in the creation of Gnome, which (although everyone has their own opinion on it) has provided KDE with some healthy competition and made lots of Gnome users happy. Who are we to say that a second Python binding won't result in similar happy results several years down the road? Maybe it will attract more people to Python, or Qt, or KDE, or all of the above?

>>Let the best implementation win.

>Maybe. As PySide takes up more that twice the memory at runtime at present, compared with PyQt, it doesn't seem to really be in the running yet. On the other hand, I think a python binding based on the Smoke libraries would be very interesting and would have some technical advantages to offer KDE (such as being smaller than PyQt). So perhaps you would prefer three competing implementations?

Oh come on! PySide is fresh, sure it uses more memory. All projects start out that way. I think KDE4 used a lot of memory in it's early releases too.


By kwilliam at Sun, 08/30/2009 - 18:08

I was thinking of trying some python KDE development, but this limbo with pyqt and pyside is really stopping that, even though pySide claims API compatibility. I would prefer a clear statement that as soon as pyside is up to the task, that then pykde moves to that. And a statement the pyKDE developers will join pySide development list to track and coordinate development.

Let's be honest here, last I read pyQt has some 100 to 200 paying customers. And now the creators of QT, backed by a multi billion dollar company and via a Brazilian (where KDE is strong) research institute will create their own python Qt bindings. Clearly with the aim of using python on maemo, and perhaps the Nokia netbooks that will come out in Q4 or 2010 Q1.

Moreover, the new lib will be LGPL, a clear improvement over the present licensing and something KDE should immediately approve of. I don't know if KDE has some convincing power with Riverside aka Phil, but it should be made clear to him that pyQt will only survive in an OSS environment if it becomes LGPL also. Licensing has always been the weakest point of KDE, and now that is finally resolved with Qt becoming LGPL, keeping it for pyKDE seems like a no brainer.

Don't get me wrong, this is OSS so people do what they like. If the aim is to have python bindings for KDE, then pyside seems the way forward. Joining that now will make that implementation better quicker, than waiting for it to be better before joining. If the aim is to use pyQt because of sip and the good architecture of it, then stick with that. It would not be the most rational and best choice for KDE though....


By bmcage at Thu, 08/27/2009 - 08:09

Pages