One of the issues that WSGI has to deal with is the question of how to connect a WSGI application and a WSGI server together, or to put it the other way, how to tell a WSGI server what to do to actually invoke your application. The WSGI specification specifically does not cover this issue, considering it a server specific issue. However, something of a standard seems to have grown up in WSGI implementations; you supply a module name (or sometimes a file), and the WSGI server expects to import this and find a callable application object that is your application.

This makes me twitch.

One of the basic rules of writing sensible Python code is that modules should do nothing when simply imported. To the extent that they absolutely must run code (instead of simply defining things), it should be minimal and focused on things like getting their imports set up right. Among other things, the more active code you run at import time the harder it is to diagnose failures and bugs by importing your module and selectively running code from it; the moment you look at your module, it explodes.

Creating a properly configured WSGI application generally requires running code, sometimes quite a lot of code. Yet you must have a callable application object ready at the end of the import. There is a conflict here, and none of the resolutions to it make me very happy.

(I can think of at least three; you can run all of that code at import time, you can write a more complex application front end that defers running it all until the first request, or you can pretend that you can configure your application through entirely passive Python declarations. The latter is the route that Django takes, and I think that it has a number of bad effects.)

What would be a great deal better is if WSGI implementations had instead standardized a function that you called in order to get a callable application object. This would allow you to have a pure and easily importable set of modules while still doing all of your configuration work before the first request came in (instead of stalling the first request while you frantically do all of the work to configure things).