Well, to be precise both Zope and CherryPy can be used with Apache, but nevermind.
Of course, everything can be used with or behind Apache.
Running serious systems with python requires a better interface than CGI anyway. Pure CGI is not supported by most projects, highly discouraged or not seldomly seen as "the last possible solution". CGI installations are most often hacky and extremely slow / resource intensive.
I must admit that supporting Python on a web server is something you don't see very often, even more seldomly along free hosting services. That might be because Python's web usage doesn't look back at such long history as PHP or Perl, but apart from that it has proven it's possibilities in many situations. There are many known web apps written in Python, such as MoinMoin or Trac to call the most famous. Beside that very specific apps Python is known for its web frameworks. Django, TurboGears, Zope - there's nothing comparable in the PHP world; or at least I don't know of any ^^. With such frameworks it's as easy as assembling ~100 LOC to write your custom CMS, wiki, blog, gallery and whatnot.
Sorry, carried away…
What I'm saying in general is: a usable Python environment on Tuxfamily would be a great new feature and many developers would profit from that. And the price for it all is as little as enabling (serious) Python support on the server. Before going into detail, I guess it's better to link you here: http://docs.python.org/howto/webservers.html That page explains incisively pretty much everything there is to know about Python in conjunction with Web.
I can't call myself a Python professional, since I'm coding it for only about 1,5 years now, but I'd be happy to help if you have a need for me.
Everything that need to change the Apache configuration is not easy at all. That would require a whole integration into VHFFS and a way to reload not one, but a cluster of webservers, and so, without causing any service disruption due to badly generated configuration.
Next, everything other than CGI require persistent processes for performance... per project... this is not scalable at all, and would require a lot of memory.
We also have some constraints due to shared hosting that must need to be taken into consideration. Each user and group have its own, respectively, UID and GID, each process must be running with the right owner and group. Each user/group can only access on the filesytem their files for security reason, it's needed for localpart set on local mails sent, it's also needed to set limits on resources on kernel side which are of course per UID/GID, for disk quota usage, and so on.
Perl has exactly the same problem Python has with CGI, ruby either ;-)
PHP, on the other side, spawn quickly, compile and run the code quickly, so it works perfectly fine with CGI, is easy to fork with the right UID/GID, run on a cluster of webservers seamlessly, it don't need any modification over time on the Apache configuration, so Apache servers don't need to be reloaded, it also don't need proxying, nor persistant processes, nor virtual machines. This is mainly why PHP is always available and others not.
We are not against about offering python through other means that CGI, but this is not something that could be done in an evening, this is a complete rewrite of how TuxFamily works for now over ten years, that would require several months of continuous work, new hardware with much much more memory, and more time needed on the day-to-day administration. For my part, I don't really see how make something which is more stable than a house of cards.