The Python community has produced many useful web application frameworks, including Django, Pylons, Turbogears, Zope, CherryPy, Paste, and many more [1]. Recently, many of these frameworks have attempted to decentralize their architectures and become more component-based, specifically using the WSGI specification [2] to decouple servers from applications, and even framework components from each other.

In general, however, each of these frameworks' and servers' natural assumption is that it alone must be in control of the OS process, generating and responding to process-wide events: startup, shutdown, and restart. As various people have tried to combine components from multiple frameworks, they generally select one framework or server as the primary process controller, and then write ad-hoc adapters to translate the startup/shutdown style of foreign components into the style of the primary controller. In many cases, this adaptation has simply not been possible when frameworks or servers are too tightly coupled to process-wide events; for example, when two frameworks register signal handlers for the same process.