# The Django Jargon

The internet contains tons of information out there about  [Django: The Web framework for perfectionists with deadlines](https://www.djangoproject.com) . 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.
## Project Structure
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:
## ```__init__.py```
According to the  [official documentation](https://docs.python.org/3/reference/import.html#regular-packages), Python defines two types of packages,  [regular packages](https://docs.python.org/3/reference/import.html#regular-packages)  and  [namespace packages](https://docs.python.org/3/reference/import.html#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```
The ```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```
```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.py```
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](https://www.python.org/dev/peps/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.
## ```manage.py```
The ```manage.py``` or ```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.