I've been trying to deploy rpmgrok (a Turbogears 1 app ) behind
mod_wsgi, and finally figured out why mod_wsgi stopped working when I
added a WSGIProcessGroup directive (which avoids having to start a new
process per http request)
I know bpeck has had similar issues with his "beaker" code 
It was working on publictest14.fp.org
, but not on my local workstation
(both RHEL-5 running mod_wsgi from EPEL).
Attempts to browse led to no response coming from httpd, and no log.
It turned out, I had mod_python installed on the box.
Upon disabling "LoadModule python_module modules/mod_python.so"
from /etc/httpd/conf.d/python.conf it worked.
Known issue? http://code.google.com/p/modwsgi/wiki/InstallationIssues
describes another mod_wsgi/mod_python incompatibility, but the symptoms
seem different 
Hope this helps
 debugging attempts led me to find "stuck" httpd threads waiting
forever for the global interpreter lock, presumably acquired by
mod_python elsewhere in the process:
#0 0x005bf402 in __kernel_vsyscall ()
#1 0x0018331e in sem_wait(a)GLIBC_2.0 ()
#2 0x01d97f3b in PyThread_acquire_lock ()
#3 0x01d74d57 in PyEval_RestoreThread ()
#4 0x01d9104f in PyGILState_Ensure () from /usr/lib/libpython2.4.so.1.0
#5 0x00c65785 in wsgi_start_process (p=0x918a550, daemon=0x92b91a8) at
#6 0x00c661b3 in wsgi_hook_init (pconf=0x918a550, ptemp=0x91b8608,
plog=0x91bc618, s=0x918c3f0) at mod_wsgi.c:8919
#7 0x00c27783 in ap_run_post_config (pconf=0x918a550, plog=0x91b8608,
#8 0x00c1311d in main (argc=152602056, argv=0x9281448)
grep /proc/$PID/maps mod_
showed mod_python to be loaded.