Rag And Bone

Usually, when writing bindings for a C library in a high level language, there’s a sweet spot where you have to leave the relative safety of an API similar to the library you are wrapping and the idiomatic correctness dictated by the language itself.

For instance, in the PyClutter bindings a typical clutter.Behaviour constructor is lifted directly from the equivalend function call:

  behaviour = clutter.BehaviourDepth(alpha, -100, 100)

  behaviour = clutter_behaviour_depth_new (alpha, -100, 100);

The ClutterAlpha parameter, though, can ben NULL, so a “keep the API similar to the C equivalent” approach would be:

  behaviour = clutter.BehaviourDepth(None, -100, 100)

  behaviour = clutter_behaviour_depth_new (NULL, -100, 100);

This is, though, different from the “pythonic” approach; as Python has the syntactic sugar to support arguments with default values, the place for those parameters would be at the end of the function call:

  behaviour = clutter.BehaviourDepth(-100, 100)

Correctness issue aside, let’s add the fact that a pythonic approach allows the poor maintainer (yours truly) to drop a lot of hand-written code.

Unfortunately, though, the pythonic approach breaks the API ((This is not a huge issue as it might seem: the underlying C library has already done that for us)); more unfortunately, it breaks the API without giving a useful error message: the PyGObject bindings will raise a not very useful

  "TypeError: could not convert parameter 'depth_start' of type 'gint'"

exception when encountering the wrong value type for the argument ((The error message should be a more useful “could not convert value of type X, and parameter Y requires a value of type Z”, which would require a bit of tinkering in the bindings themselves and it wouldn’t be useful anyway because only the new versions would pick that change up)).

The question then is: should the idiomatic correctness sway in favour of the language or the underlying library?

Here the blog post ends. I’d like to have an answer for the question, but I’m still undecided; if anyone has some insight, especially Python developers, I’d appreciate a comment

John Saw That Number

Thanks to Ross and his mad python-fu skillz, now we have a working Python binding for gtkunique – for the brave souls which may want to use it.

The repositories locations have been changed, after the servers update at OpenedHand, so here’s where the fun is:

  trunk:  bzr branch http://folks.o-hand.com/~ebassi/bzr/gtkunique
  python: bzr branch http://folks.o-hand.com/~ebassi/bzr/pygtkunique
  perl:   bzr branch http://folks.o-hand.com/~ebassi/bzr/gtkunique-perl

Testing is greatly appreciated.

gtkunique future: GtkUnique is API frozen, and feature complete as far as I’m concerned (bug fixing and eventual feature requests notwithstanding). I’ve opened a bug for integration into GTK+: #378260. You can watch it and give your opinion there.

Twist The Knife

Dear LazyWeb:

I’m trying to clean up the python bindings for the next release of a GObject-based library, so I’m using pygtk and its codegen magic; unfortunately, being codegen.py an incredibly bad program, I can’t see why or how it’s failing to read the .defs and .override files, and why it doesn’t generate anything. Is there a way to have some sort of error message or information except for the quite useless statistics recap? I’m using the same build system used by pygtk, so this must work if you apply enough bad mojo somewhere. I don’t want to dwelve into the 1707 lines of dense python – I’d rather spend my time binding a library.


Three hours, and many curses, later: it seems that I have mistakenly deleted a '%%' between a ‘ignore-blob’ declaration and the body of the override file. This, for posterity, is logically equivalent to “ignore whatever exists after this space”. which is, all in all, logically coherent, and I’m more than willing to beat my head against the wall for my stupidity. But if codegen.py had a “verbose” mode (instead of me sprinkling the code with “print” statements) I would have found this way sooner than the three hours it took me. A simple line redirected to stderr telling me “hey, I’m ignoring this and that” would have been sufficient.

How Good It Can Be

Corey, why on earth should we switch from an entire set of system configuration tools written in Perl to another one written in Python? Just for the sake of Python? Just because there are more Python zealots^Whackers on GNOME than there are Perl ones?

I understand that Ubuntu loves Python, but please: rewriting every tool in Python just for the sake of it is totally useless. What Python gives us over Perl, for system configuration backends? (No, it’s not a rethorical question: I’m serious).