Thursday, 31 March 2016

Better Django choices

A typical Django model looks something like this:

from django.db import models

class MyModel(models.Model):
        (1, "Active"),
        (2, "In-Progress"),
        (-1, "Inactive"),
    status = models.SmallIntegerField(choices=STATUS_CHOICES, default=1)

    def __str__(self):
        return '{}'.format(

To filter on "status", one would do this


Not only is hardcoding non-informative in this case, anyone reading or writing a filter has to refer to the Model every time. In the two fairly large Django codebases that I have worked on, there was a mapping system that would let you do this.


This gives better context to someone reading the code. Authors, on the other hand, still need to hardcode a string.

"There must be a better way"

Sure there is, a quick search will lead you to this.

One can pip install django-choices and call it a day. To me, this problem seems too trivial to require a dependency.

More searching will lead you to this. What I suggest is a mix of both, with some restructuring.

Create a directory named "choices" in the app's folder. For each model in your app, add a file in this directory (for "MyModel", you can add "").

For each field with choices, you define a class (with the same name capitalised).

class Status:
    ACTIVE = 1
    INACTIVE = -1

    choices = (
        (ACTIVE, "Active"),
        (IN_PROGRESS, "In-Progress"),
        (INACTIVE, "Inactive"),

MyModel will be updated likewise. An extra property of the form <model_name><capitalised_field_name> is added. You can, and probably should, experiment with the naming conventions here.

from django.db import models

from .choices import mymodel

class MyModel(models.Model):
    MyModelStatus = mymodel.Status
    status = models.SmallIntegerField(choices=MyModelStatus.choices,

    def __str__(self):
        return '{}'.format(

Filtering will be thus:


There's several enhancements you can make to the "Status" class. Such as creating a base that auto-defines "choices", gives default values, etc. This does the job without adding much overhead. It is slightly verbose, but I'd take that any day for improved readability. Authors will also benefit from autocomplete in supporting editors and IDEs.

For those who might consider refactoring an existing codebase, you can run "makemigrations" to test it out. If you did everything correctly, no changes will be detected when you run "python makemigrations".

Making changes to production systems however, based on the latest blog posts that you read, is a risk that is yours to take :)

Tuesday, 29 March 2016

Stateful Modules in Python

TIL that random.seed persists across imports, aka modules with state. (aka unintentional MonkeyPatching?)

Let's say we have "" (WARNING:  Do not rely on "random" for cryptographic purposes, use "os.urandom" instead)

import random

def get_random_numbers():
    s = random.sample(range(1000), 10)
    return s

And another file named ""

from moduleA import get_random_numbers

import random

if __name__ == '__main__':
    for i in range(3):
        # do things with random
        # code from another module that uses random

The side effect may be obvious here (prints the same random numbers on each iteration).

Perhaps .seed should be treated as a runtime context? (instead of associating state with the module)

with random.seed(1337):
    _ = random.random()

To avoid this, one can seed random with os.urandom before each use.

import random
import os

def get_random_numbers():
    s = random.sample(range(1000), 10)
    return s