== 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
http://www.python.org/dev/peps/pep-0333/]] 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 ImportTricks]]. 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).