The Django Jargon
The internet contains tons of information out there about Django: The Web framework for perfectionists with deadlines . Why do we need one more article to add to it? The motivation of writing this blog post was a good friend of mine with whom I was about to start a project. We belong from different technological backgrounds. This was going to be his first time dealing with a Django application. And it was then when I realized that he was going though the same set of curious questions that I went through when I came across Django at my first time. This blog post is meant to serve as a reference point for myself as well as you guys out there to quickly be able to grasp some of the jargon that one would typically encounter while learning to develop a Django project.
At the time of writing this article, Django had released 2.2.6 and the Django Rest Framework had version 3.10.3 out. Both of them follow the same directory structure
Project/ ├── Project │ ├── __init__.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py └── manage.py
Let's go through the basic boilerplate files created:
According to the official documentation, Python defines two types of packages, regular packages and namespace packages. Regular packages are traditional packages as they existed in Python 3.2 and earlier. A regular package is typically implemented as a directory containing a
__init__.py file. When a regular package is imported, this
__init__.py file is implicitly executed, and the objects it defines are bound to names in the package's namespace. The
__init__.py file can contain the same Python code that any other module can contain, and Python will add any additional attributes to the module when it is imported.
settings.py is a central configuration for all Django projects. Although
settings.py uses reasonable default values for practically all variables, when a Django application transitions into the real world, one must take into account a series of adjustments to efficiently run the Django application.
urls.py is the main entry point of a Django application. In most circumstances, Django uses the
django.urls.path method to achieve url path matching mechanism. However, Django also offers
django.urls.re_path method. The major difference between both these methods is that the
path method is designed to perform matches against exact strings, whereas the
re_path method is designed to perform matches against patterned strings based on regular expressions.
WSGI is the Web Server Gateway Interface. It is a specification that describes how a web server communicates with web applications, and how the web applications can be chained together to process one request. WSGI is a Python standard described in detail in PEP-3333. The
wsgi.py file contains the WSGI configuration properties for the Django project. WSGI is the recommended approach to deploy a Django aplication to production.
django-admin commands can be used interchangeably as both serve the purpose of being Django's command-line utility. The main difference is that
manage.py is used to run project-specific tasks, while
django-admin is usually preferred for system-wide Django tasks.
Note: I'm planning to update this documentation over time. Stay tuned.