Misleading ImportErrors in Django
I was debugging an issue with our Django app at work today; an admin.py file wasn't being picked up, and nothing was appearing in the admin pages. It turned that an ImportError was being thrown in the admin.py and Django was interpreting this as the file not existing.
I'm assuming that the reason for this is that Django uses __import__ to import the module, and catches ImportError's if the admin.py doesn't exist. The trouble with this is that if admin.py does exist, and throws an ImportError of its own, Django will also interpret that as a missing admin.py – which can be misleading.
The only solution I can think of to more accurately handle this would be to programmaticaly examine the traceback to determine where the ImportError is thrown. If the traceback is one level deep, we know that the ImportError was thrown because the module doesn't exists. If it is greater than one level then we know the module was found, but has thrown an ImportError of its own.
Here's a simple proof of concept:
#check_import.py import traceback import sys def check_import(name): try: __import__(name) except ImportError: exceptionType, exceptionValue, exceptionTraceback = sys.exc_info() return len(traceback.extract_tb(exceptionTraceback)) > 1 return True print check_import("os") print check_import("noimport") print check_import("anotherlevel")
#anotherlevel.py import thismoduledoesnotexist
This produces the following when run:
True
False
True
It would be nice if Django did something similar for its implicit imports. I think the best behaviour would be re-raise the ImportError if it the module does actually exist. That way, it is clear what the problem is. I may attempt to write a patch at some point, unless someone knows of a better solution.
“ #Django 's auto-discover mechanism can't distinguish between a .py file not existing and one which throws an ImportError ”
0The low-down on Django-Techblog
I figured I would write-up some of the features of Django Techblog, the blogging application I wrote to power this site. It does most of what you would expect from a blogging app, but there are a few features that it does differently. The main difference is extended markup, but there are a couple of other features that worthy of note:
- Multi-blog capable. I want to blog on a variety of subjects, but because some of the things I post about (namely the geeky stuff) are only of interest to a select few, I risk turning away visitors who aren't interested in those techy posts. Categories and tags are one solution to this, but I prefer to have a number of blogs under an umbrella blog, each with its own posts, templates and tags. In Techblog, there is also a concept of a channel which appears exactly like a blog from the front-end, but aggregates posts & tags from one or more blogs. In this site, the home-page at / is actually a channel consisting of /blog/tech/ and /blog/personal.
- Microblogging. Techblog has support for Twitter and potentially other microblogging services could be added. You add your twitter account details, which Techblog uses to poll your tweets and automatically post them to a specified blog. It filters out replies because they are rarely of interest to anyone other than who the reply is intended for, and also parses hashtags to create equivalent tags in the blog system. A microblog post can have a unique template (just a Django template) so they can have a different look and feel to regular posts. You can check my tweets in /blog/microblog/.
Getting the Code
The code for Django-techblog is licensed under my politeware license, which means you can use it for any purpose you see fit, but I would appreciate a thank you! It shouldn't be too difficult to set-up if you have worked with Django, but I'd be happy to help if you experience any problems with it. See the Google Code page for the SVN url:
http://code.google.com/p/djangotechblog/
Fast Caching with Django and Nginx
I've been toying with optimizing the caching on my blog recently – for my own interest (this humble blog doesn't get all that much traffic). All the same, any speed improvements will only mean snappier page-loads and greater capacity to handle a slashdotting, or similar.
I discovered that Nginx has a memcached module that can serve pages directly from memcached without touching the file-system, or a downstream web-app. Which makes for very fast response times. To get it working, you need to set a cache key named with the url of the page, and the value to the HTML. Alas, this means that it would not work with Django's caching mechanism due to the way Django caches unique pages based on the contents of the request header.
More on extended-markup
In my last post I introduced extended-markup, which is the light-weight markup system used to generate posts in Django-Techblog. I'll cover a few other things it can do in this post.
When the Post model is saved to the database, the extended markup is parsed in to a structure that is basically a dictionary containing a list of chunks, and associated variables. The order that the chunks appear in each section is the same as the order they appear in the markup, unless a chunk variable called priority is defined. This causes the chunks to be sorted in descending order of priority, chunks without a priority value are assigned a default of 100.
Django Techblog markup system
Django Tech Blog is now running my blog. It is only fitting that my first post on the new system is about the technology behind it.
I never intended to compete with Wordpress on number of features, and Techblog was never intended to be an all-things-to-everyone type of web application, but I can boast a few features that set it apart. I'll cover some of those features in future posts, for now I would like to go over the light-weight markup language I use for posts.
