I just sent off my first patch for Django. It adds the ability to send mail via SMTP servers which require authentication. I need this for Dreamhost, which has authentication on its mail servers.

The modifications were simple, and the code I was modifying was refreshingly clean. Better yet, the Django project site gives easy and clear instructions about how to contribute. So, I’m feeling very good about the project, the ease of contributing, and the maturity of the code.

Update (next day): They accepted the patch and merged it into the trunk of the dev version. I updated SVN and it is all there. That is the fastest response ever for one of my patches to be accepted into a public open-source project!

[tags]django,dreamhost[/tags]

Last night I took a break from my most recent Django app, a mailing-list manager, to explore the new "Magic Removal Branch".

I diligently followed the instructions on the Django Wiki to change my existing code. There were more changes needed than I’d anticipated, but they all made sense, so I didn’t mind. Better, I agreed philosophically with all of them.

Basically, the idea is to make Django apps act more like normal Python modules. That means ceasing all the “magic”, where it used to automatically provide entire new classes to manage objects, and used to magically move around the modules, making them available in namespaces you hadn’t explicitly named. I found that confusing, to be honest. I always had to look at example code to find out where the magic stuff was going to be. The magic, which was supposed to be helpful, actually ended up costing me time and thought.

Roadblock 1 – Database Init

Unfortunately, I’m not all the way there yet in migrating my code. First, I ran into a significant problem with database initialization. That is, it didn’t work.

$ bin/admin.py init

File "/sw/lib/python2.4/site-packages/django/core/management.py", line 498, in init
contenttypes_app = models.get_app('contenttypes')

File "/sw/lib/python2.4/site-packages/django/db/models/loading.py", line 30, in get_app
raise ImproperlyConfigured, "App with label %s could not be found" % app_label

ImproperlyConfigured: App with label contenttypes could not be found

OK, I restored the old database. It was a good thing I backed up before trying this! I then executed the SQL recommended on the Wiki to convert an existing install to the new branch. That mostly worked, but complained that a few tables were missing. “django_flatpages”? Never used that one, I assume it was a contrib module.

Roadblock 2 – code changes

I think I’ve converted all the existing code correctly, but the server dies on start. Apparently, I did not convert my old "”Class META" to the new "Class Admin" correctly. I’m sure I’ll knock that problem down the next time I have a moment to tackle the conversion. Unfortunately, I ran out of time, exhausting the one hour I had left before “The Daily Show” last night.

Conclusions

Absolutely worth the pain. It will work with a little more tweaking. These are normal pains to experience when using a pre-release, actively developed branch.

Update: The contenttypes error is corrected by a patch available from bug #1280.
[tags]django,python,magic removal[/tags]

One nice thing about Django is that unlike many frameworks, you do not have to “grok” the whole thing to be productive. In my case, I hadn’t read a lot of the documentation other than the tutorial and the details of a few of the features I need for my first app.

Surprise!

Imagine my happy surprise when I found the very nicely implemented “documentation” link in the automatically generated admin site. I’d assumed it was a link to the static documentation or some such thing, like it is in most systems. Nope. It is much more.

It has details and documentation on everything I’ve done on the site. I habitually put in docstrings, so they are formatted for me and presented on the detail pages for my model objects. Wow. This is automatic, and a big incentive to keep doing that documentation! Every view is similarly detailed. In fact, there are auto-generated pages for Tags, Filters, Models, and Views. In each case, the documentation only shows things valid for the application. If you’ve added custom tags, they are there, along with all the built-in ones.

I hate to rave, but this level of detail and usefulness is unprecedented in my professional experience. Especially in a free and open programming framework.

[tags]Django,documentation,raves,python[/tags]

Django is pulling ahead of every other web framework I’ve tried. For reference, that includes such recent heavy-hitters as: Jakarta Struts/Tiles, Spring, PHP Smarty, Zope, and Plone.

I’d been thinking about why that was so, why I’ve become so fond of Django so quickly, when I ran across a post at Jacobian.org, titled Why you should use Django. I’ll take his top ten points and add my own observations:

1. Django works — right now

It really does. The example tutorial works correctly the first time. That is something hard to find in the online world. Better, there is no outstanding wart which is holding up adoption, and which will be fixed “real soon now”.

2. Deployment is a breeze

I know that I will be able to deploy on DreamHost, which is the most important part to me as a user at this time. As a developer, it was amazingly simple to set up and run my development system. This took literally hours less time than setting up an equivalent Java system.

3. Your site won’t go down

That’s one of Django’s big claims, and is part of the reason I was initially attracted to the framework. It speaks of quality to me.

4. Django is fast

It is faster by far than Kid, and Cheetah. If it beats those, then it literally blows Zope out of the water. PHP should eat its dust as well. But that is all beside the point to me at this point. I care about “fast to develop for”, and that is where it truly shines for me.

5. Django scales

Not qualified to judge.

6. Django’s admin will blow your mind

I hate writing admin interfaces. Django removes almost all the pain for me. In fact, they are almost free, which is a wonderful and deeply appreciated thing. How many times have I released a half-ass admin interface “for trained users only” to justify the fact that using it might cripple the site if the wrong button were clicked? More times than I like to think. Django won’t prevent all of that, but it gives me back so much time that I can then use to put in better logic-checking and validation.

7. You don’t need to go whole-hog

I am preparing to port Invisible Castle to Django, and I’ll report back about my progress. I expect it to be fairly easy, actually.

8. Django plays well with designers

I’m not qualified to judge, I think he’s probably right

9. Django comes from the Real World

I love the fact that they don’t add functionality just because it looks fun. The best projects/software in the world were built to solve real problems, and more importantly had real users right from the get-go. Django was built exactly that way, with immediate feedback and guidance from their sponsor, and it has clearly benefited from that.

10. We’re here to help

My post about logging in frameworks which referenced Django was picked-up and responded to within a day. That’s amazing. What’s more, the result is that they may very well adopt what I am suggesting. It wasn’t a flame-fest, despite my initial harsh tone. The professionalism and openness both surprised and pleased me.

[tags]python,django,webframeworks,web frameworks[/tags]