The web frameworks (or non frameworks as some like to call themselves) for which instructions are currently provided for mod_wsgi are CherryPy, Django, Karrigell, Pylons, TurboGears and web.py. Instructions for each have all been up for more than a month on the mod_wsgi web site, so for the analysis I have taken the statistics for the month of August. For that period, the number of unique page views against each was as follows:
FWIW, the mod_wsgi documentation also provides instructions for using Trac and MoinMoin on top of mod_wsgi. The number of unique page views for these packages was:
Although interesting, these results cannot tell the whole picture for a variety of reasons. These include whether or not respective packages actually reference mod_wsgi (or how prominently) as a hosting solution in their own documentation and how often I have personally referred to mod_wsgi on each packages mailing lists as an alternate solution to a particular persons problem.
Beyond those issues, there are actually a number of technically related reasons as to why for a particular package there may not have been as much traffic to the mod_wsgi web site.
The main issue is that although all are capable of being hosted using Apache and mod_wsgi, of the web frameworks only Django promotes strongly the idea that for production sites one should use Apache. At the moment the recommendation in that respect is mod_python, but at least the idea of using Apache is not a foreign concept. Thus for Django, the builtin web server is only seen as being a practical hosting solution for a development instance of Django.
For most of the other packages they instead see the builtin web server they provide as being capable enough to support a production site. Thus, although they may describe or reference other ways of hosting a site developed using the package, the only way that Apache generally factors into the equation is as a proxy to their own web server and as a means of hosting static files.
As far as using a web server implemented in pure Python as opposed to hosting on top of Apache, there does also seem to be a reasonable amount of bias against using Apache. In part this appears to be due to some ignorance as to the pros and cons of using Apache and how to set it up properly, but also partly because of Python zealotry. In other words, just like every programming language, some are so strongly enamoured by Python that they simply cannot except that there are other ways of doing things.
Such a pro Python only stance could actually be seen as being detrimental to the chances of Python being accepted within commodity web hosting. This is because commodity web hosting companies will not find it acceptable that they would have to setup and support pure Python back end web server applications to which they merely proxy requests.
Instead, commodity web hosting want a system that can be easily integrated with their existing Apache installations (normally setup for PHP), yet doesn't place undue memory requirements and overhead on Apache. Above all, the ability to provide hosting for Python web applications must be very simple to configure and fit in with the large scale automated systems they have for configuring the many sites they would host using one Apache installation.
Thus in some respects, packages which try to steer developers to always using the builtin web server are only going to make it harder for that package to be accepted by web hosting companies. Some thought must be given to ensuring that packages are easy to deploy and setup under Apache in a web hosting environment. If this is not done, then you will not see those packages being supported by web hosting companies and as a result people will simply move to those packages which have put in the effort to make it easy to deploy under Apache.