Virtualenv Bash Shell Function

By default, virtualenv uses /usr/bin/python. I find this a pain because I run the latest Python out of /usr/local/bin. Each time I create a new virtualenv environment, I need to type:

virtualenv -p /usr/local/bin/python {env}

If you use Bash, create the following shell function to save precious keystrokes or guard against creating your virtualenv with the ancient python interpreter included as the system default:

function virtualenv()
/usr/local/bin/virtualenv -p /usr/local/bin/python "$@"

Simply place the above in your Bash config file. This is your .bashrc, .bash_profile, or .bash_login file, depending on your Unix variant platform.

(To figure out which one, see here:

By the way, when you create a shell function with the same name as the shell program/script, make sure you have the full path of the program specified in the shell function. IF you don’t, the shell will resolve the command back to the shell function. And you are stuck in an infinite recursive loop (turtles all the way down…)

Tagged with: , ,
Posted in Computing, Programming, Python

Time with family and practice smoking meat

No real blog post this weekend. Instead, spending more time with family and learning to use my smoker grill. What you see are pork ribs and a pork loin cut in half.


Posted in Cuisine

Python Under the Hood: A simple generic model, part 1

Tonight I was digging through the SQLAlchemy and SQLSoup source code to help figure out what I’m doing wrong with my object mapping for in-memory sqlite. While doing this, I figured out how to make a very simple but powerful “value” object [1]. If you are a beginner or intermediate Python programmer, you may have seen where Python seems to magically add named attributes and methods to instantiated classes (objects). SQLSoup and lxml’s Objectify do this, as well as many other packages and modules. SQLSoup does table and field auto-discovery, saving you the effort of defining the table classes and mappings. When you instantiate against an existing database, like this (from the SQLSoup tutorial)

>>> import sqlsoup
>>> db = sqlsoup.SQLSoup('postgresql://scott:tiger@localhost/test') 

Then you can access tables and fields in an intuitive way, as shown below

>>> user = db.users.filter('John Baldwin').one() 

You don’t have to go through the following nonsense to get the email address for a particular object (table row)

 >>> email = user.get_field('email') 

This is a very common pattern in Python, and one of its many great features. Python, as a dynamically types language, is very powerful, but can cause a lot of problems if you don’t treat this power with respect and pay attention to detail. One measure of respect is that you need to be thorough with your testing when writing production code.

So even though I have no practical need at this time, I wrote a generic “value” object that can create all of its attributes from the constructor:

from collections import OrderedDict

class GenericModel(object):

    def __init__(self, *args, **kwargs):

        # probably unnecessary, but guarantees order by the numeric key
        self.attrs = OrderedDict(
            sorted({ k : args[k] for k in range(0, len(args)) }.items()))

        for k,v in kwargs.iteritems():
            setattr(self, k, v)

    def __getitem__(self, key):
        return self.attrs.get(key)

    def __setitem__(self, key, value):
        self.attrs[key] = value

    def __iter__(self):
        return iter(self.attrs.values())

    def __len__(self):
        return len(self.attrs)

Here is an example using GenericModel:

 >>> a = GenericModel('foo', 'bar', 'baz', soup='No soup for you', help='You are on your own')
 >>> a.soup
 'No soup for you'
 'You are on your own'
 >>> len(a)
 >>> a[0]
 >>> a[1]
 >>> a[2]
 >>> for i in a:
 ... print i

So what we have is a class which has named attributes for keyword arguments (**kwargs) and can be an iterable for the variable arguments (*args). I will explain what is going on in part 2.

[1] Technically, this is not a value object. A value object is immutable.

Tagged with:
Posted in Computing, Programming, Python Unknown command: ‘createsuperuser’


When you need to create a superuser, the official Django documentation says to run createsuperuser. Instead, run the following:

$ python createsuperuser

The Details

While putting together a tutorial for Django, I started to explore how a project behaves if I didn’t create a superuser when running syncdb for the first time. My first question was how do you create a superuser after running syncdb.

I found the following documentation to create a superuser: createuser createuser

Following the documentation, I ran createsuperuser and got an “unknown command error.” Here is the full output for this set of steps:

(djangobox)$ python syncdb
Creating tables ...
Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_groups
Creating table auth_user_user_permissions
Creating table auth_user
Creating table django_content_type
Creating table django_session
Creating table django_site

You just installed Django's auth system, which means you don't have any superusers defined.
Would you like to create one now? (yes/no): no
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)
(djangobox)$ createsuperuser
Unknown command: 'createsuperuser'
Type ' help' for usage.

So I looked in my project’s to find that django.contrib.auth was indeed installed. So what gives? In my opinion, the official Django documentation is wrong or misleading, depending on which side of the hair you split. Let me explain.

When you create a superuser, you are creating one for a specific project. Therefore needs to know which project is the target. The conventional way to perform commands on existing projects is to use, which provides the project and settings information for the Django admin tools. To create a superuser for a Django project, run the following:

$ python createsuperuser

This allows us to create a superuser if we said no when we ran python syncdb to instantiate the initial project database. We can also add additional superusers if we want.

Back to the error we got when we tried to create a superuser with django-admin:

(djangobox)$ createsuperuser
Unknown command: 'createsuperuser'
Type ' help' for usage.

The reason this command failed is that the createsuperuser command is from the django.contrib.auth package, which is not loaded when you run with the default installation configuration (at least without specifying a project or database). These tools, and the project specific are convenience scripts around ManagementUtility in the package. This utility system is extensible. When you add a package to the INSTALLED_APPS dictionary in a project’s file, it will add management commands, if it has any, to Run without parameters, and you will see what commands are available:

Available subcommands:





when you run on its own, it only shows what is under the [django] list of subcommands.

When you read the source code to, you’ll see something like the following:

from django.core import management

if __name__ == "__main__":

When you read the source code to, you’ll see something like:

#!/usr/bin/env python
import os
import sys 

if __name__ == "__main__":
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings")

    from import execute_from_command_line


You see the commonality: both call’s method execute_from_command_line.  This function is a wrapper around the ManagementUtility class in the package. No project contexts are provided to, but is provided in The directory which contains will have the project directory (in this case “mysite”), which has the project’s file. sets an environment variable for the project and the settings file, then calls the convenience function, passing our parameters to it. If you are interested in poking around the Django source, ManagementUtility is in

To continue on with my explanation, lets look to the official Django docs. Read the red underlined text.


This is not actually the case. does not wrap around I’m not clear why this is stated. This is, in implementation, not accurate. They are both thin wrappers around There could be a misunderstanding of the documentation writers that got carried forward and hasn’t been fixed. It could have been how Django operated prior to version 1.0. Or it is a conceptual simplification: The interface behavior of acts as if it is a thin wrapper around, since it provides the project specific context, while does not. At this time, I don’t know, and this is a minor nit about the generally excellent documentation, which has helped Django gain its popularity. My thanks to the documenters for all their good work.

Hopefully this post has shed light on some of the mechanics of the Django admin scripts. The main takeaway should be that when you read the djangodocs and they use for commands specific to a project and that project is not part of the parameters, then use instead.

Tagged with: , , , ,
Posted in Computing, Django, Programming, Python, Web Frameworks

How old is that salsa in the fridge?

You pull a jar of salsa out of the fridge. You don’t remember when you opened it up. A week ago, 2 months? maybe 3?


I used to run into this problem more than I liked. We’d throw out food because we couldn’t remember when we opened it. Having been a former Army cook and before then, an AP Bio student, I have food safety burned into my brain.

Jars, cans, pouches, vacuum packs, not to mention frozen items, they’ve got a long shelf life. But once opened, most foods have a much shorter lifespan, even with the wonders of refrigeration.

So I got the idea to write down the date when I opened up a jar (tub, resealable pouch, can, etc) before I stuck it in the fridge. I now make sure I keep a permanent marker or two in the kitchen. At first it was easy to forget to do, but after a few months it became second nature.

Until someone invents a device which automatically counts how long something has sat in your fridge, this is the simplest and most cost effective way I’ve found to track the venerability of your refrigerator denizens.

If you get into the habit of writing today’s date on it before putting it in the fridge, then you won’t have to play guessing games with the food that you put in the fridge. I don’t have any advice for your family and guests, except locking your fridge or going through even more unsociable extremes.

Tagged with: ,
Posted in Cuisine

Dict (Dictionary) Comprehensions in Python

In my never ending quest to grok Python and do more while writing less code, I came across dict (dictionary) comprehensions. See PEP 274.

Dict comprehensions are the dictionary analog to list comprehensions. This post provides a simple problem space, introduces list comprehensions with an example, then shows a similar pattern and example using dict comprehensions.

Problem space:

Let’s say we are using a dictionary to store some of our application settings. It is common for absolute paths to be used in the application configuration settings (Django projects mandate absolute paths in, for example). You either have to hardcode them, or somehow dynamically derive an absolute path.
One practice is to get the directory of the current file, this one from django-all-auth:

PROJECT_ROOT = os.path.normpath(os.path.dirname(os.path.abspath(__file__)))

For our simple example, I’m making the decision that our app data are going to have their own directory in the user’s home directory.


List comprehensions:

For those not familiar with list comprehensions, it is a way to create a list from an iterable sequence. This sequence could be one or more source lists, iterables or generators. Here is an example of using a list comprehension to create the :

import os
# define our list of relative paths our application will need
rel_paths = [ 'myapp', 'myapp/log', 'myapp/data', 'myapp/media']

# Use a list comprehension to get the absolute paths
abs_paths = [os.path.join(os.environ['HOME'],path) for path in rel_paths]

So now when the app needs to create a new log file, it can reference abs_paths[1], and get something like


Its important to note that the above does not assume that the actual application is executed out of $HOME/myapp, only the application data files are assumed to be there.

Now our list approach has a serious limitation: Lack of context. When you are deep in your code and you need to load an image file form your media folder, you’re going to have to remember that the media folder is in abs_path[3]. What happens if you or someone else inserts and element before ‘my app/media’ in your rel_paths list? Yes, abs_path[3] now doesn’t point to where it should and you have a bug. This is one of the many reasons why dictionaries are so useful.

rel_paths = {
'APP_HOME' : 'myapp',
'LOG_DIR' : 'myapp/log',
'DATA_DIR' : 'myapp/data',
'MEDIA_DIR' : 'myapp/media',

So now have both a mnemonic instead of an index for our setting and more robust code. As long as we don’t change the keys names, we can rearrange, insert new key-value pairs without impacting any other code. But we still have a relative path for each directory and need to get the absolute paths. Here’s how:

Dict comprehensions:

Dict comprehensions operate the same way, but use two variables, the key and its value, instead of the typically single value for list iteration.

abs_paths = { k: os.path.join(os.environ['HOME'], v) for (k,v) in rel_paths.iteritems() }

The only differences in syntax are:
1. We use braces instead of brackets. We are specifying the container type here
2. We specify the key:value pair in our expression
3. We identify the key and value variable names as a tuple following the for clause. in reality, there is no syntactic difference with this part of the comprehension syntax. Lists can have tuples to define the values used in the expression. Example:

a = [(1,2), (3,4), (5,6)]
b = [x*y for (x,y) in a]

Tagged with: , ,
Posted in Computing, Python

Django Boston – User Authentication

Last night was my first Django Boston meetup. Max Uhlenhuth, one of the organizers, greeted me as I arrived. We chatted for a bit before the talks started. First up: Eddy Wong, CTO of Wanderu (who provided the space and bought pizza), gave a brief presentation about his company, their adventure to SXSW, and their technology stack.

The main talk followed with Ted Teiken, co-founder of SittingAround. He gave a very effective presentation on a number of topics related to user registration and user management with Django, whether site local or through a social networking services, such as Facebook and Twitter. Ted described the capabilities that Django provides, and what it leaves to the developer. He then went over a number of apps to provide the missing functionality. Conclusion: try out django-allauth. It handles local and social authentication in one package, has reasonable defaults, and takes a minimum of effort to stand-up. The flip side is that it is an maturing tool, but not yet mature. If you need more mature tools, then Ted recommends a combination of django-registration and django-social-auth to get much of what you need done, albeit with significantly more plumbing work on the developer’s part. So now I’ve got something new to explore.

After the talk we moved on to “Howl at the Moon” around the corner, where Kryuus bought the first round (Thanks!). I chatted with some of the Django Boston folks there for a while. I have to say I learned a good deal, reinforced some assumptions I have, and had a great overall experience. I look forward to the next meetup.

Tagged with: , , ,
Posted in Computing, Python, Web Frameworks

Get every new post delivered to your Inbox.