If you’ve got Django view code that gets & sets session values, you’ll want to test it properly, and the standard “self.client” from Django’s TestCase doesn’t really give you a usable session.  So, here’s the method I’m using:

def stuff_session(client, dictionary):
    """Given a client (self.client in a unit test TestCase) set the session to the contents of
    the dictionary given"""
    from django.conf import settings
    from django.utils.importlib import import_module
    engine = import_module(settings.SESSION_ENGINE)
    store = engine.SessionStore()
    store.save()  # we need to make load() work, or the cookie isworthless
    client.cookies[settings.SESSION_COOKIE_NAME] = store.session_key
    session = client.session
    session.update(dictionary)
    session.save()
    # and now remember to re-login!

So, in my setUp() methods, I just call stuff_session(self.client, {‘key’: ‘value’}) and it all works out great.

• Python 2.7.1 from python.org
• virtualenv (manages python packages and dependencies)
• Visual Studio 2008 (for compiling Python addons)
• PostgreSQL 8.4 (database engine)
• Django 1.3 (our web framework)
• Windows psycopg2 installer

It will be possible to install any other requirements (PIL, etc.) using pip after the virtualenv is set up.

Note on 32-bit versus 64-bit

Most modern computers these days are 64-bit capable, and will (usually) be running a 64-bit operating system.  In addition, they can also run older 32-bit binaries.  When you install all the components below, you must choose either

Install Visual C++ 2008 Express Edition with SP1

This is the compiler tool needed to build other python extensions we’ll be adding later. Download it from Microsoft.   Select “Visual C++ 2008 Express Edition with SP1″, choose your Language and click the “Free Download” button.

You must use the 2008 edition, since that’s the compiler that was used to build Python 2.7.1, and the compiler versions must match for the additions to be compatible.  If you already have a newer version of Visual Studio installed, please also install the 2008 edition I’ve linked to.

You do not need to install the Silverlight runtime or Microsoft SQL Server, unless you think you want these for other purposes.

This compiler is only 32-bit capable, so we’ll be sticking to 32-bit Python below.  This shouldn’t cause any issues for most development installs.  If you have an official purchased version of Visual C++ 2008 that’s 64-bit, then you’re on your own.

Install 32-bit Python 2.7.1 from python.org

Start on python.org and select “Python 2.7.1 Windows Installer”.  Please do not choose the x86-64 Installer, as it isn’t compatible with the compiler from above.

Download and install python-2.7.1.msi

• Select “Install for all users”
• Use the default location of “C:\Python27″ (note: no period)
• Use the default options on “Customize Python”.

Install setuptools from python.org

setuptools is a Python package that facilitates installing other packages (and thus, bootstrapping your install system).  We’ll use setuptools to install other packages, but first we need to install it.  Get it from python.org.  I’m using “setuptools-0.6c11.win32-py2.7.exe”  Download and run that binary, and use the default options in the installer.

Install PostgreSQL 8.4

This will be your database server.  We use this version because it mirrors what we use in the production environment.  Select the 8.4.8-1 installer for Windows.

Run the installer and use the default install options. You’ll need to choose a password for the postgres user.  Choose something you won’t forget.

You do not need to run the “Stack Builder” tool.  Un-check that option and finish your install.

Install psycopg2 for windows

psycopg2 is the interface API from PostgreSQL to Python.  Unfortunately, it’s not packaged in a way that’s easy to install automatically, so you have to download and install it.  Choose the proper version for your Python (likely 2.7, 32-bit as we’ve discussed  before).  Here’s a link to all the available packages.

Install virtualenv

virtualenv is a Python tools that helps us manage and install Python packages in a neat and clean way.  It also helps the installation of these packages to other systems (like to our deployment environment, which is likely Linux). Run:

C:\>cd \Python27\Scripts
C:\Python27\Scripts>easy_install virtualenv

From this point forward, we won’t use easy_install anymore.

Create a development environment using virtualenv

The virtualenv tool will create an “environment” where you can install any needed Python packages, like Django.  This environment contains specially modified versions of Python and other tools that make dependency management much, much easier.  Choose a directory for your environment.  I like to put things in /Home/<username>/Desktop/src/<environment_name>  for easy access.

C:\Users\Steve Lacy\Desktop>mkdir src
C:\Users\Steve Lacy\Desktop>cd src
C:\Users\Steve Lacy\Desktop\src>mkdir test
C:\Users\Steve Lacy\Desktop\src>cd test
C:\Users\Steve Lacy\Desktop\src\test>\Python27\Scripts\virtualenv --no-site-packages --distribute env

This will create an environment in src\test\env and populate it with modified versions of Python, pip, etc.

You’ll need to “activate” this environment to start using it.  virtualenv puts in a simple activate script to help you do this, like this:

C:\Users\Steve Lacy\Desktop\src\test>env\Scripts\activate.bat
(env) C:\Users\Steve Lacy\Desktop\src\test>

Note how your prompt changed to say that you’re using development enviroment “env” which we named above.

Now that our environment is “active” we have easy access to the special versions of python and pip that have been placed in env/Scripts.  They’re now on your PATH, so you can use them directly.

Install Django using pip

This is fairly easy now that we’re in our environment and it’s active:

(env) C:\Users\Steve Lacy\Desktop\src\test>pip install django

Inspect the terminal output carefully to make sure that it successfully installs each of these. Once that’s complete, you should be good to go.

You can create a new Django project by running:

(env) C:\Users\Steve Lacy\Desktop\src\test>python env\Scripts\django-admin.py

From here, your best bet is to continue to the Django tutorial and introductions…

{% for item in list %}
  {% if forloop.first %}<ul>{% endif %}
  <li>{{ item.value }}</li>
  {% if forloop.last %}</ul>{% endif %}
{% empty %}
  <p>No items in list.</p>
{% endif %}

Is there a cleaner way to do this? It’s a lot of code for creating a simple loop.  I’m tempted to make a “listloop” class that wraps up all the ul and li logic right into the templatetag, but that seems like it hides a lot.

What I wanted was to have my django.wsgi script use the production settings and to have bin/django use the development settings.  Sounds easy, right?  It’s not obvious what the right way to accomplish this is, but here’s what I’ve come up with for my zc.buildout script:

[buildout]
parts = django djangoprod

[django]
recipe = djangorecipe
version = 1.2
settings = development
project = project 

[djangoprod]
recipe = djangorecipe
version = ${django:version}
settings = production
wsgi = true
project = ${django:project}

By specifying 2 different djangorecipe based rules, we can create both bin/django and bin/djangoprod.wsgi.  djangoprod.wsgi will use production settings, and bin/django will use development settings, which is in general, what you want for a develop & deploy buildout script.

• Python.  Use Python 2.7 from python.org http://python.org/download/.  I recommend avoiding the 3rd party Python distributions (ActiveState, Enthought, etc.) and sticking with the official build.  As a note, this python is (currently) built with Video Studio 2008.
• Visual Studio Express 2008.  Note the 2008 part.  The version Python is built with much match the version used to build extensions.  This is currently still available from the Microsoft download site, but is a bit buried under a couple links.  When installing, don’t bother installing SQL Server 2008.  You won’t need it.
• PostgreSQL 8.4.  I chose this version because it most closely matched my Linux deployment.  Download and run the installer from http://www.enterprisedb.com/products/pgdownload.do#windows and make sure to choose version 8.4.
• setuptools from http://pypi.python.org/pypi/setuptools#windows.  This will allow you to easily download and install other package add-ons.

Next, you’ll need to manually modify your PATH to include Python & PostgreSQL.    Go to Control Panel->System->Advanced system settings->Environment Variables, and make sure that your Path contains:

C:\Python27\;C:\Python27\Scripts;C:\Program Files\PostgreSQL\8.4\bin

Then, you’ll need to install some extra Python libraries:

C:\> easy_install pil
C:\> easy_install psycopg2

Then, you can run your zc.buildout script to bring in everything else.

# a,b, and c have come from some external data source, QuerySet, etc.
a = 'axis_1'
b = 'axis_2'
c = 'axis_3'
d = 'value'
if a not in context:
  context[a] = {}
if b not in context:
  context[a][b] = {}
if c not in context:
  context[a][b][c] = value

Or some variant thereof. Is there a better pattern for multi-dimensional (arbitrary) dicts in Python/Django? The setdefault() method doesn’t have the right semantics for this operation, and I’m not sure that it would actually work right for multi-dimensional arrays anyway.

Our goal is to make the site as welcoming and informative to as many people as possible.  That includes Dads, Grandparents, parents of older children, people without children, as well as expecting couples.  Come on by and share ideas & advice!

It’s easy to sign up and ask or answer a question!

We also have a blog and a facebook page, so you can follow what we’re doing on the site.

The issue is that I’ve updated my models.py with some Haystack code.  The code at hand is in the save() method of the model object, and basically looks like this:

[... other misc django imports above ... ]
from haystack import site

class MyModel(models.Model):
    [ ... fields of model, etc. ... ]
    def save(self, force_insert=False, force_update=False):
        super(MyModel, self).save(force_insert, force_update)
        if self.is_child_node():
            site.get_index(MyModel).update_object(self.parent)

The problem was that if I had a standalone script that said:

from mysite.models import MyModel

Then I would get a circular import, because the “from haystack import site” line ends up working it’s way over to search_sites.py that says “haystack.autodiscover()” which ends up looking for all search_indexes.py, and one of these says “from myapp.models import MyModel”.  So, there’s your circular reference.

The solution to this problem is to put a haystack import at the top of my standalone script, before I import my model.  Adding “from haystack import site” works, even though the code therein doesn’t actually use haystack.

I think the haystack code here:

/usr/lib/python2.5/site-packages/haystack/__init__.py in autodiscover()
 88         # Step 3: import the app's search_index file. If this has errors we want them
 89         # to bubble up.
---> 90         __import__("%s.search_indexes" % app)
 91
 92 # Make sure the site gets loaded.

Should have a try/except block around it, and then this extra import wouldn’t be necessary. The funny thing is that looking at the source, all the other imports there catch ImportError and don’t pass it back up, but this case does.

I was able to simply debug this in ipython my running “from myapp.models import MyModel” and debugging, per above.  It was fairly clear that it’s a circular import.  I’m surprised (in general) that Python doesn’t handle circular imports any more gracefully than saying “<type ‘exceptions.ImportError’>: cannot import name MyModel”

If you would like to pprint your Django Context (or RequestContext) object from within a template itself, there are several approaches you can take.  The easiest way I found is to say:

context['context'] = context

in your view(s) that you want to display, and then in the template, you can say:

{% for c in context %}
<p>{{ c|pprint }}</p>
{% endfor %}

Or something along those lines.

The reason that the simple {{ context|pprint }} doesn’t output what you expect is because of the __repr__() method on the Context() object in Django.  It constructs a big huge string for you, when what you want is to let pprint do all the heavy lifting and indentation.

Being a reasonable person, I wanted to have a separate file for each view in my system.  In other words, I want to create a views directory, with __init__.py inside, and my view files in there.  Not being a Python expert, I found this harder than expected.  Here’s what you need to do:

1. Create a views directory.
2. Split views.py into one file per method in the new views directory.
3. Edit views/__init__.py and for each view, say “from myview import *”
4. Use your views as you previously did in urls.py

I’ve heard some rumblings that you could create an __init__.py that did something like go through every file in the current directory and import everything there.  That seems a bit over the top, and I’m happy to manage the imports in __init__.py for now.

I believe a very similar technique should work for Models, but I haven’t tested it.