How to get rid of Django’s global state?

[Rollo Konig-Brock]

Refactoring larger Django projects can be a serious pain because so much state is global.

Django depends on a few major singleton objects: the settings singleton; the LRU cache that stores the URL configuration; the app registry; and the database dictionary singleton.

In this way Django compares really negatively to Flask, where you can have more than one application object.  It might seem like a niche use case, but being able to compartmentalise everything related to WSGI is really useful for refactoring and testing. 

Being able to have multiple WSGIHandler classes would enable a Django server to be included as a sub application in another WSGI application.  This might sound like a niche use case, but it’s really powerful when you need to do full rewrites of applications that have their own middleware and settings.

This would also make testing libraries easier.  As you could setup and tear down an entire Django instance in each test, without having to resort to a multitude of patches.

It would be great for Django, if ‘django.setup()’ didn’t have the multitude of side effects, and instead returned a container of all the state of that instance of Django.

Rollo