-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13-03-04 07:34 AM, Evan Dandrea wrote: >> "From exceptions to segfaults" is quite a harsh exaggeration. > >>> from gi.repository import GdkX11 GdkX11.get_default_xdisplay() > [1] 10593 segmentation fault (core dumped) ipython > >>> import gtk gtk.gdk.display_get_default() > None
As a developer who has spent the better part of the last two years developing a desktop application using PyGObject, I am no stranger to python code that segfaults instead of raising exceptions. Sometimes it was my fault for tickling the APIs incorrectly, sometimes I discovered genuine bugs in the C libs that were promptly fixed when I reported bugs. But the important thing to remember about GI is that it has *enormously* reduced the language bindings maintenance burden. pygtk2 was a *huge* codebase, and updating it to the new gtk3 APIs would have been untenable. There simply was not enough manpower available to undertake such a task. GI was the blessing that allowed Python developers to use GTK3 *at all*. I would like to hold up GExiv2 as a smaller case study in the successes of GI. The pyexiv2 module that it replaced was on the order of 10,000 lines of glue code, which existed purely to allow python to call into libexiv2 code written in C. It suffered from many layers of glue code and introduced a bunch of baroque APIs not present in the original libexiv2 library. It was a maintenance nightmare and proved nigh-impossible to port to Python3. On the other hand, I added GI annotations to Yorba's existing GExiv2 Vala library over a single weekend. I only had to write about 100 lines of code, and the API was suddenly importable and usable in Python 2, Python 3, and even Javascript, among many others. The maintenance burden is almost non-existent; it's just so simple that it blows the alternatives right out of the water. I feel quite strongly that the odd segfault is a small price to pay for an otherwise *enormous* improvement in efficiency, API coverage, maintenance burden, etc. I would go so far as to say that GI is one of the *best* technologies to come out of the GNOME project, and it's something that I am going to sorely miss as we transition to Qml. > I think it also speaks to the problem faced whenever you > mechanically generate bindings. These are not Pythonic. For someone > versed in that language, writing Object.new() is entirely alien. There exist overrides to provide the syntactic sugar that most python programmers have come to expect. >> But what do we get from switching from GI to QML? We won't have >> bindings to a great many libraries at all any more, and now have >> to go back to writing C++ stubs for those. I. e. exactly the >> problem that GI already fixed. > > That of course assumes we pick Python as the language for > graphical applications and services. Last I checked, it wasn't the > fastest thing going on an ARM processor. And the system > requirements should bar it from ever being used for a long-running > (ubuntuone-syncdaemon) or frequent process (Lenses). Yes, yes, we are discouraging python on the phone. GI is equally capable of allowing C libs to be imported into Javascript code, and Qml lets you hack in Javascript, too... so what happens now if we want to import the *wealth* of gobject based libraries into Qml? Well, you have to write a bunch of C++ wrapper glue code to get at it... it's a waste of effort and introduces extra maintenance burden. I would *really* like to see Qml adopt some form of support for GI to make it easier to call GObject libs from within Qml's JS implementation. > Or we could keep creating choose your own adventures of pain: > http://blogs.adobe.com/penguinswf/files/penguinswf/linuxaudio.png http://xkcd.com/927/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJRNRhCAAoJEMnVpoCaWglEPVcQAJyHOCVRG1/yc9eh76gouqTE /4eJTsjjxJ6SfehVwV1PkMlhknp8tDnJYKpoD8otXuzXB7HxksN8IP9Qsw/dzReN pUhHNvlAl8t/ai+kql/RpI98QkPEF2rdY0jptM1f0dk21FGlP3i3af+gEiZF9M46 8gY4nHMLzJfieVFnZgvaQap34wckBSv5i2RGPWh57MxKs+TouVUyevlPaDojstfb Cb21zR/AJF9EMrDi9L3kir+9YYka3ri/96tDx9i4M2InBAZL3t9VNUFya+U100yf 7GZRm7n+34GJBCRpLOSy/Ikt08zbnNdky12DzJfDtZDEeaB1BewJSp4PuqbiKOW6 xDpoSHFyGlDp8j/raaCdOZEye7F/gsir6xOpWTjslbkHrCCkTADlnGxKuB4EquLl SI7W1AXT3WXuda6AZWWWFxSNAGR3DBvtdZVFlUEiqT2dqT73JFUmky4gcU+vdpJU 1hvQVAHzE7D/2p5KTL2bxhkULmG+FE3Z80g+GOv64hUJZjyB8qxMnofw1r+wCuUv E6mugZJv9/1Zl4SDC4zT0WVerkoGTq4+3hD/kb3xbzIXbWCepyuq/QbCPfVOrMrn zvQHJi/nVjtDrmySIqY5a/XEswdlExk76XApJLJ2eF79SQdV/vdmnEZqXGgz5kT4 5wGfBEqO1VijVUr0XTQT =8kIb -----END PGP SIGNATURE----- -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
