Great post as always. Coming myself from PHP (in terms of web programming) I can relate to a lot of this. Now I'm involved into Zope (3) a lot, so I guess that should tell you something too :).
Several times you try to compare mod_python to mod_php. I think a better comparison would be mod_python vs. mod_perl. Both of those modules are about writing Apache handlers in the respective languages. mod_php isn't really about writing specific handlers but about a new type of page.
I'm not quite comfortable with your aiming at CGI. With WSGI and paste (after all, that's your invention :)) I think we can offer more flexibility. A mod_python WSGI handler is available, setting it up (especially with paste) is a no-brainer. I hear your saying "the constraint is a feature". I still think that it can be just as easy with an obvious default option while still providing a choice for other servers platforms.
I find the idea of having a Pythonic PHP-like web tool that a) works without threads, b) has a simple web toolbox like PHP (but better organized), c) easy database access and d) a decent way to do sensible HTML templating with the ability to add Python scripting in between (ZPT has that in a fully XML-wellformed manner) very appealing. Building it isn't probably the real challenge even. Making it scale (not in a performance sense but in a size and complexity of project sense) is. In Zope we have the problem that we want to scale down (perhaps to something similar to what you're suggesting) so that people can get familiar with Zope on a small scale and then work their way up. Similarly, your "Better PHP" would have to be able to scale up eventually when people decide to extend their apps, make them reusable, etc.
My reference to CGI is merely to acknowledge that it is the only current system that really is fully like PHP; but it's not a practical way forward for Python. It just doesn't scale to complex code -- it scales well for lots and lots of users, but for large codebases it performs badly. PHP's CGI-like model might be part of why object-oriented code is not very well valued there -- PHP punishes large codebases more than Python. (Which is why I noted PHP doesn't have a built-in large codebase like Python does in the standard library.)
I would just like to see a single preferred, really good process and server model for Python; not to the exclusion of anything else, but something we can point people to as a good starting point. There's a handful of issues that need to be solved on that level that haven't been solved yet (like reloading), and it just needs to be done right. WSGI is still very handy, particularly because it means that building that server isn't a prerequesite for work on other levels, and that it won't invalidate that other work in the future. WSGI allows diversity, but because it means we can make more granular decisions it also means we should eventually start consolidating around certain best-of-breed pieces at some of the levels of the stack that can now be chosen independently of other parts. In this case there's no server that I think is good enough currently, but we're close, and it would be a good thing to tackle at this time. And the result should perform every bit as well as CGI in all the ways CGI performs well.# Ian Bicking