Django’s standard library lives in the django.contrib package. Each subpackage is a standalone add-on feature package. These subpackages are generally independent of one another, though some django.contrib subpackages depend on other subpackages.

There is no hard requirement on the kinds of functions in django.contrib. Some of these packages ship with models (and therefore require you to install the corresponding database tables), while others consist of standalone middleware and template tags.

The feature shared by all django.contrib development packages is this: even if you delete the entire django.contrib development package, you can still use Django’s basic functionality without running into any problems. When Django developers add new features to the framework, they decide whether to put the new feature into django.contrib strictly according to this principle.

django.contrib consists of the following development packages:

• admin : an automated site administration tool
• admindocs: provides automatic documentation for Django admin sites
• auth : Django’s user authentication framework
• comments : a comment application
• contenttypes : a framework for introducing document types, where every installed Django module acts as an independent document type.
• csrf : this module defends against cross-site request forgery (CSRF)
• databrowse: a Django application that helps you browse data
• flatpages : a module that manages single HTML content items in the database
• formtools: a set of advanced libraries for handling common form patterns.
• gis: an extension that provides GIS (Geographic Information Systems) support for Django
• humanize : a series of Django module filters used to make data more human-friendly.
• localflavor: mixed snippets of code for different countries and cultures.
• markup : a series of Django template filters implementing some common markup languages.
• redirects : a framework for managing redirects.
• sessions : Django’s session framework
• sitemaps : a framework for generating the XML files of a site map.
• sites : a framework that lets you manage multiple websites within the same database and Django installation.
• syndication : a framework that uses RSS and Atom to generate syndicated feeds.
• webdesign: Django extensions that are very useful to designers.

Other django directories:

• conf.
  It mainly serves two purposes: (1) handling global configuration, such as the database, loaded apps, MiddleWare, etc. (2) handling urls configuration, that is, the mapping relationship between urls and views.
• core.
  Django’s core processing library, including url resolution, request handling, caching, etc., among which request handling is the core; for example, handling fastcgi is done by-
  wsgi.py.
• db.
  As the name suggests, it handles everything related to the database, i.e. the ORM.
• dispatch (to dispatch, to send out)
  Actually this is not original to Django; it is the pydispatch library, and it mainly handles the consumer-worker pattern.
• forms.
  Handles html forms
• middleware.
  Middleware, which handles the HTTP request and response, similar to a plugin. For example, one function of the default common middleware: when a page does not find the matching pattern, it automatically adds ‘/’ and processes it again. For instance, when visiting /blog, while the defined pattern is ‘^blog/$’, no matching pattern is found, so it automatically looks it up again with /blog/ — provided, of course, that APPEND_SLASH=True.
• template.
  Django’s templates
• templatetags.
  A wrapper for handling an Application’s tags: it adds all the templatetags directories in INSTALLED_APPS to the django.templatetags directory, so that when you use load blog to load tags, you can load them via import django.templatetags.blog. There is one problem with this, though: if another Application directory also has blog.py, the tag from the first blog.py that appears will be loaded.
• utils.
  A common library; many shared classes live here.
• views
  The most basic view methods.