I have an issue with the wait() method of Condition which doesn't seem 
to respect the timeout it is given: I couldn't create a simple example 
to reproduce the bug, because if I try to do something small and simple 
everything works as expected, but in the actual code it doesn't work, 
so here's the link to the code:

http://github.com/Kjir/amsn2/blob/
bda6829d0c7d50a1cbf1188cdfa3789c4b7967c5/amsn2/gui/front_ends/curses/
contact_list.py

The most interesting function is the last one, where there is a wait 
with timeout of 1 second. If I have a look at the logs, after the 
initial download of the list there is nothing happening, while I'd 
expect to see a "check" cycle every second or so. If there is a 
notification arriving, the whole thing fires up and updates the contact 
list as expected, but the timeout itself doesn't work.

I don't know if there could be a problem with other modules, for 
instance gobject, but if there is then you should update the 
documentation to point out such incompatibilities.

If you could help me to create a simpler program to test this issue I 
would happy to provide you a test case, but I am out of ideas right now 
on how to narrow down the issue.

If you want to download the code and test it, here are the instructions:
git clone git://github.com/Kjir/amsn2.git
cd amsn2
git checkout -b curses_cl origin/curs_cl
python amsn2.py -f curses 2>> run.log
Log in with an msn account, tail -f run.log in another terminal to 
watch the logs

If you want to se what happens on a notify, one of your contacts should 
change status.

And here are a very brief explanation on how the code is called, if you 
need it:
the whole code is divided in basically three areas, core, protocol and 
gui. I am working on the gui side and the methods contactListUpdated, 
groupUpdated and contactUpdated are called by the core through a 
gobject signal.

My python version is 2.5.2 on gentoo amd64, use flags:
berkdb gdbm ipv6 ncurses readline ssl threads tk xml
-build -doc -elibc_uclibc -examples -sqlite -ucs2 -wininst

If you need anything else, just ask!

Oh and here's the link to the posts on comp.lang.python:
http://groups.google.com/group/comp.lang.python/browse_thread/
thread/7fc388c30304bf22#

Ok I fixed the issue thanks to the help from Piet van Oostrum: I didn't 
call gobject.threads_init(), so that gave the unexpected behaviour. It 
is certainly bad documentation on the gobject side, but you may 
consider adding some kind of warning on the threading documentation 
page, since I guess gobject is quite commonly used.

I don't think we need warnings about third party libraries in our docs.