A little thing that irritates me about common WSGI implementations
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
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
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
application object ready at the end of the
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).