Django is not a framework but a Protocol

This has been a concept that has been brewing in my mind for the last couple of months. It's been mostly inspired by my desire to see a prodserver (final name TBC) in Django Core alongside runserver and why it sitting happily as third-party package would, to me, not be a sufficient solution.

As part of some research on potential names for commands I dug into the django-tasks DEP to understand how the worker would be started. My findings found that it will be currently left to future iterations with the current solution delegated to the implementation (read a third-party package).

Additionally Carlton's talk at DjangoCon Europe this year teased at the idea of modularization, how can we break up Django for some aspects to ship faster. I too have toyed this with in the past in regard to the contrib) module. Carlton has also written about Django having a grain, a natural way of working, to the extent that I would say we have Djangonic?! code in addition to code being Pythonic.

Finally to reference the Zen of Python:

There should be one-- and preferably only one --obvious way to do it.

This has become harder to see as time as gone on with the number of third-party packages exploding in some areas. However their are some clear exceptions to the confusion, third-party database backends will generally have a clear choice (maintenence dependent), the other would be storage backends, cache backends or template backends. The commonality here is that Django provides a very clear API surface and settings pattern to integrate with. Yes, you still have the choice in which database, storage or cache to choose from, but when it comes of how to do it in Django it's very clear.

So the main responsibility of Django Core is to fulfil that line from the Zen of Python, by continuing to provide a clear one obvious way to get a job done with most implementation details existing outside of core. When you view Django in this light it is definitely less about the code, but the API Design decisions that have led to a Protocol for creating web applications using Python.

... and yes I do think prodserver would fill that design gap for specifying how production processes should be started (along with simple-deploy for deployments). 😉