I admit it, I’m a long-time PHP programmer. I got stuck with it for a long time with all my web-based stuff, simply because it is so easy to set up. Well, there is no set-up, it just works. You just add pages to your web server root and give a .php extension to them, and they get requests and give back responses. Nice and simple.

I still use PHP for quick and dirty things (like running shell commands through web interfaces – yes, really, really naughty…) For doing more complex work, I prefer Python. But I miss the PHP-like way of just adding pages or “web applications” with zero-setup. I will examine the possibilities in Python for this kind of behaviour in this article.

Please remember, there are many, some say even too many, Python web frameworks available already that handle all this stuff for you “automagically”. You are almost certainly better off with using one of them, if you want to get work done. But they all require some kind of setup work.

Then there’s the thing with all kinds of frameworks, that instead of you calling some library, the behaviour of which you understand, to do your work, a framework calls your code. That is all right when things work as expected. But whenever there are glitches, you need to start digging around the framework code to see exactly what’s wrong. And if it is a big framework, that could mean a lot of digging around. For that reason, if you’re a reasonably seasoned programmer, I think it might not be half bad an idea to create your own minimalistic framework, using existing, good quality libraries the behaviour of which you understand, and which you can easily poke in the Python shell if you think something’s not working like it should. Or just to see what’s available, and try out the available code.

Also, knowing how stuff works never hurts. This article is also about learning how the Apache http requests are dispatched to Python code through mod_wsgi. I insist on knowing how things work, so I’m doing it the hard way. Continue reading Serving Python scripts with Apache mod_wsgi, part I →