On my system with pycairo 1.8.6 and pygtk 2.14.1 the commands run without error.

The last function call in your example which gives the problem is a pygtk/pangocairo call not a pycairo call. So why do you think this is a pycairo and not a pygtk problem? Try to strip out the pygtk calls and reproduce the problem using only pycairo.

When you say "seems to be still open in version 1.8.6", what do you mean?
Have you tested it on your system? What versions of pycairo and pygtk produce the problem?

The thread you mention shows one person having a problem followed by 2 responders who said the commands worked fine on their system. So it could just be a misconfiguration on one machine or one specific Linux distribution.

If you can reproduce the problem on pycairo 1.8.6, and reduce it to an example that does not use pangocairo that would be very useful.

Ok, I'll try to be more specific. To clear things up, I don't know much about pycairo, I'm just a tool (w3af) that is using a library (xdot.py) that is using pycairo. I didn't know that some of those calls are from pygtk.

However, I can reproduce the problem mentioned in the list with pygtk-2.14.1 and pycairo-1.8.6 / pycairo-1.8.2 on Arch Linux. Arch, unless many other distros, normally takes software directly from upstream without changing anything, so I think the problem is not with the packages.

I have pygtk-2.14.1 installed as a binary package, but I have built pycairo myself. Arch makes it very easy to build packages from source, which I did using the following PKGBUILD (they are quite easy to read):

-----------------------------------------------
pkgname=pycairo
pkgver=1.8.2
pkgrel=1
pkgdesc="Python bindings for the cairo graphics library"
arch=(i686 x86_64)
license=('LGPL' 'MPL')
depends=('python' 'cairo>=1.8.8')
options=('!libtool')
source=(http://cairographics.org/releases/${pkgname}-${pkgver}.tar.gz)
url="http://www.cairographics.org/"
md5sums=('bbfc0c2fef08dfb0c5b8baa5f0b67a87')

build() {
  cd "${srcdir}/${pkgname}-${pkgver}"
  ./configure --prefix=/usr || return 1
  make || return 1
  make DESTDIR="${pkgdir}" install || return 1
}
-----------------------------------------------

When I install the created package for pycairo-1.8.2, the cairo.FontOptions() objects seems to be fine, as I do not get any errors. Installing pycairo-1.8.6 (built with the same technique) fails with the error mentioned in the description of the bug.

It seems to me that something has changed between 1.8.2 and later versions regarding the object which you get back when calling cairo.FontOptions(). So the question is, did something change and the pygtk folks have to update their code as well, or is it a bug in pycairo?

I hope this comment is specific enough to give you some more hints on where the problem could be.

Try this using pycairo 1.8.6. Its the test case you gave with the pygtk/pangocairo parts removed:

>>> import cairo
>>> surface = cairo.ImageSurface(cairo.FORMAT_ARGB32, 100, 100)
>>> ctx = cairo.Context(surface)
>>> options = cairo.FontOptions()
>>> options.set_hint_metrics(cairo.HINT_METRICS_OFF)
>>> ctx.set_font_options(options)

If it works it demonstrates that in pycairo 1.8.6 cairo.Context.set_font_options() is working correctly.

Now build from source pycairo 1.8.6 and then pygtk-2.14.1, in that order.
The pycairo C API changed in 1.8.4, so pycairo 1.8.6 will not work properly with a pygtk-2.14.1 which has been compiled against pycairo 1.8.2.

If this works file a bug with Arch Linux to let them know that when using
pycairo 1.8.6, pygtk should be compiled against pycairo 1.8.6 and not earlier versions.

You're absolutely right, the problem is that pygtk in Arch Linux seems to be compiled against pycairo-1.8.2. After recompiling, everything works. I will file this bug with Arch Linux.

Thanks for taking the time to go through this with me, I really appreciate the effort.

Steve, shouldn't pycairo .so version be bumped when the ABI change such that these things don't happen?

Behdad, As far as I know, Python extension modules tend to be loosely coupled so this problem does not occur for most Python modules, and consequently Python does not have any support to handle this problem by using soname versions. 
If you know how it can be handled, I'd be interested to find out. Especially since the next pycairo version is likely to have the same problem.

Normally libtool's -version-info does that.  However, you pass -avoid-version to libtool, so the version info is not used.  The -avoid-version is typically used for modules.  It is not appropriate for modules that are also used as normal libraries linked from other libraries IMO.  The Python community should know better.