I switched to explicit imports of things in our Django application

February 4, 2024

When I wrote our Django application it was a long time ago, I didn't know Django, and I was sort of in a hurry, so I used what I believe was the style at the time for Django of often doing broad imports of things from both Django modules and especially the application's other modules:

from django.conf.urls import *
from accounts.models import *

This wasn't universal; even at the time it was apparently partly the style to import only specific things from Django modules, and I followed that style in our code.

However, when I moved the application to Python 3 I also switched all of these over to specific imports. This wasn't required by Django (or by Python 3); instead, I did it because it made my editor complain less. Specifically it made Flycheck in GNU Emacs complain less (in my setup). I decided to do this change because I wanted to use Flycheck's list of issues to check for other, more serious issues, and because Flycheck specifically listed all of the missing or unknown imports. Because Flycheck listed them for me, I could readily write down everything it was reporting and see the errors vanish. When I had everything necessary imported, Flycheck was nicely quiet (about that).

Some of the import lines wound up being rather long (as you can imagine, the application's views.py uses a lot of things from our models.py). Even still, this is probably better for a future version of me who has to look at this code later. Some of what comes from the application models is obvious (like core object types), but not all of it; I was using some imported functions as well, and now the imports explicitly lists where they come from. And for Django modules, now I have a list of what I'm using from them (often not much), so if things change in a future Django version (such as the move from django.conf.urls to django.urls), I'll be better placed to track down the new locations and names.

In theory I could have made this change at any time. In practice, I only made it once I'd configured GNU Emacs for good Python editing and learned about Flycheck's ability to show me the full error list. Before then all of the pieces were two spread apart and too awkward for me to reach for.

(Of course, this isn't the first time that my available tools have influenced how I programmed in a way that I noticed.)


Comments on this page:

By James at 2024-02-06 10:28:26:

Explicit imports also let you know what you can mock for unit tests.

For example if you wanted to mock out the external call a python module makes, you would do:

```python

from unittest.mock import patch

def test_response():

   with patch("myapp.module.fetch_google", return_value="somevalue") as m:
       assert call_function_under_test() == "some_assertion"

```

And your test would return whatever needed value for some external call you wouldn't want to actually make.

Written on 04 February 2024.
« Solving one of our Django problems in a sideways, brute force way
We might want to regularly keep track of how important each server is »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Sun Feb 4 21:50:01 2024
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.