Slacy’s Blog

Just a quick note to my readers and searchers that we’ve launched our new parenting website, Parents Guild.  We’ve got question & answering, e-mail notifications, tagging, voting, and a bunch of other parenting-specific features in the works.  We’ve got about 50 users so far, which is pretty great considering we haven’t done much marketing.   We’re welcoming feedback (use the link on the left hand side of the site, or comment here, or comment on the blog or facebook).

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.

So, in converting our search to Haystack, I’ve found that some of my standalone maintainence scripts no longer work.  They had an import error trying to import some of the models.

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”

This was non-obvious to me for quite some time, and I tried several different approaches before settling on this one:

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.

So, I’ve been doing some Django programming on the side, and the thing that annoys me is that Django forces you to put nearly all your source code into 2 files:  models.py and views.py

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.