Hi Richard, Your e-mail is quite long and touches various different issues (around the same topic), so I will comment just on some items.
* Yes, we knew about Smoke during PySide conception, as we already told you on IRC. We also experimented with a lot of technologies, that included even ctypes(!). Boost::Python was in fact one of that last ones we tried. * Why we not picked Smoke? I can't say because I didn't try it myself (we did a kind of distributed evaluation and shared results with the entire team, there was a lot of things to test!), but I can talk a little from my experience with the Gobject-based Python bindings, while working on the PyMaemo (Python for Maemo) project. GObject Introspection based bindings is a new thing on the stable distributions. At least in the last months, the latest version of PyGtk/PyGobject bindings in Debian/Ubuntu still uses the "old" approach, based on a tool called "codegen" that, surprise, **generates direct Python/C "static" code** (with a little help from pygobject for some dynamic parts). This is what the Python for Maemo (the Linux based OS that runs on Nokia's Internet Tablets) has been using for the last 4 years or so, and it proved to be fast/small enough for many applications written in PyGtk available for Maemo. Of course there are many places for improvement. On the other hand, "dynamic" based bindings are still a untested technology on embedded devices (If you know of any embedded device that uses fully introspect-based bindings, specially for Python, please let me know). I am personally interested on comparing performance/resource usage between the two approaches and might to so for PyMaemo at some point. Please note that all this is for C code only. C++ libraries have their own problems in embedded devices, specially the size that tends to be a lot bigger than C ones. Anyway, my point is that while dynamic bindings look modern and apparently simpler/smaller, I am still a bit worried about it lacking proper use cases in the embedded Linux-based devices (please, show me that I am wrong! I would love to see full introspection everywhere), and specially how much CPU overhead it introduces due to various "table lookups" necessary for introspection. Some caching is of course possible, but how efficient it is in terms of CPU usage (that translates to battery usage in embedded devices)? * Boost::Python was selected amongst the others because of its integration between C++ and the Python/C API, based on the "intelligence" provided by the compiler that allows to (semi-)automatically manage exceptions, type conversions and so on. But all of this came to a price: while we achieved some impressive performance (at least for such a initial release), the generated bindings turned out to be _quite_ big. We attempted to improve this by approaching some Boost::Python developers and looking for ideas (there are other big bindings based on Boost::Python too, but not as big as Qt+PySide) and how the compiler could help us, but still using the modern C++ techniques requires a lot of type information to be stored on the binary. Heavy template instantiation also did not help on the size (although proved to be quite efficient). Therefore we turned to play with the shiboken concept. You can find a couple of blog posts about it written by Marcelo Lira (AKA setanta), just search for shiboken on google (there should not be a lot of unrelated references, as it is a random name chosen by us :) * I'll not comment further on your last PyQt comment, it does not bring any technical value IMHO. * Finally, we spent quite some time on the binding generator itself, reusing work from QtScript generator and the typesystem concept. One of PySide's strength (in my opinion) is also providing the tools to generate bindings for any C++ library you like (although currently limited to Qt based ones, but this changing on shiboken, made to be generic since day one). The Qt bindings of course are our main focus. Note that the latest code for the generator is becoming plugin based, so Boost::Python (or shiboken, or smoke, or...) will just become a backend for it. Ideally, this will allow *anyone* to play with new/experimental binding concepts, and we will be able to finally and honestly compare performance/size between the approaches. Just my two cents, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil _______________________________________________ PySide mailing list [email protected] http://lists.openbossa.org/listinfo/pyside
