The Most Advised Way to Use Imports in django

Introduction

In our Django Projects, all the Python files should follow standard coding conventions. Here I have listed the best ways to use imports in Django Project.

Advice 1: PEP 8 Standard

PEP 8 suggests that imports should be grouped in the following order:

1. Standard library imports
2. Related third-party imports
3. Local application or library specific imports
4. Imports from the apps that you created as part of your Django project.

Example

# Stdlib imports
from math import sin, cos
from operator import itemgetter

# Core Django imports
from django.db import connections
from django.shortcuts import render_to_response

# Third-party app imports
from django_extensions.db.models import TimeStampedModel

# Imports from your apps
from home.models import Postcode

Advice 2: Use Relative Import

Always use relative imports in your project in such a way that it’s easier to move, rename, and version your work. In Django, relative imports remove the need for hardcoding app name.

In our Django Project (Let's suppose we have pricing_profile apps in our project to keep track of price for different user profile group), we generally import like the below code.

# pricing_profile/views.py
# Hard coding of package name
from django.views.generic import CreateView

# DON’T DO THIS: Hardcoding of the 'pricing_profile' package
from pricing_profile.models import PriceGroup
from pricing_profile.forms import PriceGroupForm

class PriceGroupCreateView(CreateView):
  model = PriceGroup
  form_class = PriceGroupForm

This code is ok. It will not throw any error but it has some hardcoded imports that will make it less portable and reusable. Let's suppose you fall in the following condition, what will you do?

1. You want to use your pricing_profile app in your different projects, but you had to change its name because of name conflict with other apps.
2. What if you simply want to change its name to pricing.

With hardcoded imports like the above, you have to go through all your project files and change its name
everywhere. So it's better to use relative imports to avoid such situations.

Example

# pricing_profile/views.py
from django.views.generic import CreateView

from .models import PriceGroup
from .forms import PriceGroupForm

class PriceGroupCreateView(CreateView):
  model = PriceGroup
  form_class = PriceGroupForm

Advice 3: Avoid Import *

Everywhere in your Django project, try to explicitly import each module with name, avoid using import *.

# Never DO THIS
from django.forms import *
from django.db.models import *

1. If you will use import * in your project, it will unnecessarily import all modules. Let's suppose it has 100 modules, then it will load all even if you require only 2 modules in your project.
2. Other problem with using import * is namespace collison. If both the Django Forms and Django Models libraries have a class called Charfield by implicitly loading both libraries, the Models library overwrote the Form version of the CharField class.

Advice 4: Use Grouping to Import Multiple Names

If you want to import a lot of names from a module or package, you have to choose one of several options:

Option 1

#Write a long line with backslash continuations:
from Tkinter import Tk, Frame, Button, Entry, Canvas, Text, \
    LEFT, DISABLED, NORMAL, RIDGE, END

Option 2

#Write multiple import statements:
from Tkinter import Tk, Frame, Button, Entry, Canvas, Text
from Tkinter import LEFT, DISABLED, NORMAL, RIDGE, END

Option 3

#Use Python grouping mechanism (parentheses) to write the import statement:
from Tkinter import (Tk, Frame, Button, Entry, Canvas, Text,
    LEFT, DISABLED, NORMAL, RIDGE, END)

Option 3 is the best option to import multiple names from a module or package.