I wanted to make a model field where the underlying data is a string, but the field on model instances exposes more attributes. Specifically, a MarkdownField:

class Document(models.Model):
    text = MarkdownField()

that exposes a way to get at its content as both HTML and source Markdown:

>>> doc = Document(text="hello, *world*")
>>> doc.text
"hello, *world*"
>>> doc.text.html
"hello, <strong>world</strong>"

This is not too uncommon in Django-land – for example, Django’s built-in FileFields work this way. Surprisingly, the pattern for accomplishing this doesn’t seem to be documented anywhere (that I can find), so here we go.

Starting today, Django has a new governance model. Previously, a small “core team” made most decisions, including electing a Technical Board to own decisions about each release. Now, the “core team” is gone; all power rests with the Technical Board. Anyone who’s made substantial contributions to Django is now eligible to run, and the board is now elected by the DSF Membership at large. You can read more about the change in today’s announcement, and if you want to full details they’re in DEP 10. 

Videos from Django Under the Hood 2016 are up - check ’em out! As usual, the conference was amazing and the content was fantastic. I really enjoyed all the talks, and they’re all worth your time to talk. Three in particular stood out to me as exceptional highlights:

1. Ana’s talk on Testing in Django is the single best talk on effective testing of Django apps I’ve ever seen. I really like her technique of explaining Django’s testing APIs by looking at how they changed over time: it does a great job of explaining what problems particular APIs solve, and why you’d use them. Most testing talks don’t do a great job talking about use cases; Ana’s breaks the mold.

Django’s admin site is about 12 years old. It started circa early 2004 as an internal CMS at the Lawrence Journal-World, was released as part of Django in 2005, and has been chugging away ever since. There’s been some substantial re-writes along the way – magic-removal, new forms, the flat theme – but for the most part the admin’s stayed pretty much the same for that entire time. The interface, functionality, and CRUD-oriented workflow haven’t really changed since those early years at the Journal-World.

Adrian broke the news: today, he and I are retiring as BDFLs, transitioning to a truly community-run project.

Adrian wrote a bit about the history of the BDFL term and our roles wearing that hat. Go check out his writing for that, and for some of his personal thoughts. Here, I’ll just add a few things of my own:

For me, this has been a long time coming – I’ve been thinking about this for at least a year. In many ways, I this is a similar to a lot of the changes we’ve made over the years: it’s a formalization, and a naming, of what’s already happened. It’s clear to me I don’t have the sort of day-to-day involvement that I once had, and I can’t remember the last time I’ve had to make the sort of dictatorial decisions that the title implies.

Getting new features into Django isn’t easy. It’s that way for a reason — I spoke recently about why conservatism is a virtue — but it does happen. I’d like to do a better job explaining how we decide what goes in and what goes out, so here’s a lightly adapted version of something I posted on the mailing list this evening. It’s three things I look for when I’m trying to determine whether something is “right” for Django or not:

In 2007, and again in 2009, I made an attempt to measure the size of the Django community. By popular request — okay, a couple people asked for it, whatever — let’s do this thing again.

Here’s a thought that’s been rummaging around in my brain for some time now: is there a market for commercial, closed-source Django apps?

Suppose someone released a high-quality, well-documented, well-supported Django app… under a commercial license. Assume of course that this app does something you actually need, and that the commercial license isn’t odious. Would you pay for a Django app?

I think I would. I have no qualms about paying for good software: in the last month I bought some backup software (Arq), started using a commercial ticket tracker (Pivotal) and time tracker (Freckle). In all cases, free/libre alternatives existed, but the paid versions were easier, slicker, faster, or in some sense “better.” Enough so that they justified their prices (to me). I think if Haystack (to pick an arbitrary example) was commercial (and reasonably priced) I’d pay for it — the time required to build an alternative would almost certainly cost me more.

(Cross-posted from the Revsys blog; I think folks here might be interested, too.)

Next month I’ll be teaching two new one-day classes, both of which evolved from common questions we get at Revsys. Each class is going to be offered twice, once in LA and once in Boston.

For the impatient here are some links and quick info:

• Django Deployment Workshop - Los Angeles - December 6, 2010.
• Django Deployment Workshop - Boston - December 10, 2010.
• The Best of the Django Ecosystem - Los Angeles - December 7, 2010.
• The Best of the Django Ecosystem - Boston - December 9, 2010.

For more details on each class, read on…

Since 1.0, Django’s supported model inheritance. It’s a neat feature, and can go a long way towards increasing flexibility in your modeling options.

However, model inheritance also offers a really excellent opportunity to shoot yourself in the foot: concrete (multi-table) inheritance. If you’re using concrete inheritance, Django creates implicit joins back to the parent table on nearly every query. This can completely devastate your database’s performance.

To refresh, if you’ve got models like:

On Twitter, I asked, “what’s your favorite third-party Django app?” Eight hours later, I’ve got about 50 replies.

I meant the question to be fairly open-ended – I deliberately didn’t clarify what I meant by “favorite” – and I’m not that popular, so this is by no means an accurate sample of the Django community. Still, the answers are a bit interesting, so let’s take a look:

D’oh:

django/contrib/admin/util.py
django/contrib/admindocs/utils.py
django/contrib/comments/views/utils.py
django/contrib/formtools/utils.py
django/contrib/gis/db/backends/util.py
django/contrib/gis/tests/utils.py
django/contrib/localflavor/it/util.py
django/contrib/localflavor/se/utils.py
django/contrib/localflavor/uy/util.py
django/contrib/messages/utils.py
django/core/files/utils.py
django/core/mail/utils.py
django/db/backends/util.py
django/db/utils.py
django/forms/util.py
django/http/utils.py
django/test/utils.py
tests/regressiontests/forms/util.py

I had the pleasure of being on a forms panel at PyCon 2010 chaired by Brandon Craig Rhodes. To get a stable baseline, Brandon asked each of us to provide code showing how each forms toolkit might tackle a problem:

Imagine that someone has already written a form with your forms library. The form looks something like this:

New username:    __________
Password:        __________
Repeat password: __________
    [Submit]

Now, someone from Marketing comes along and announces that the developers must add some additional questions to the form - and the number of extra questions is not determined until runtime! They give you a get_questions(request) function that looks up a profile they cook up for each person browsing the site, and returns a list of strings like one of these:

Early registration ends Friday for the March Advanced Django Class I’m teaching, so if you’re planning on coming, you should sign up soon!

I’m really excited about this class: we’ll get to dive really deep into the good parts of Django. We’ll cover all sorts of advanced usage of Django’s APIs, spend a bunch of time playing with all the cool stuff out there in the Django ecosystem, and actually spend a whole day setting up and configuring a real-world deployment stack.

In March of 2007, I attempted to measure the size of Django’s community. That March turned out to be a major inflection point in Django’s growth: the release of 0.96 brought a lot of new features – testing and the new forms library being the critical ones – and those in turn brought in a lot of new users. Growth since then has been at a much faster pace.

So I thought it’d be interesting to review the same metrics I used back then. I was quite curious to see what’s changed, and by how much.

It’s fashionable, or perhaps inevitable, for tech communities to trash their competition. The Emacs folks like to mock vi users; Windows folk look down on us Mac users (and Linux users mock us both); and everyone likes to mock PHP despite PHP’s dominance in the web world. We geeks make arguing over minor technical points into a kind of art.

This is all pretty understandable: it’s easy to define community in terms of what we’re not. A common enemy focuses and drives us. Competition can take a positive form: when it’s friendly and constructive both communities benefit.

I’m pleased to announce that I’m teaming up with Steve Holden and Holden Web to teach a one-day Django Master Class. The class’ll be in Washington, DC on October 16th, 2009. I’ll be covering a grab-bag of advanced Django tricks, including AJAX, REST, schema migration, testing, caching, code quality, and more. Hopefully there’ll be something there for everything.

For more info or to sign up, head on over to Holden Web

A quick reminder: if you’re thinking of coming to me week-long Django course in Kansas City next month, today’s the last day to sign up at early-bird pricing. The price goes up by $500 tomorrow.

It’s shaping up to be a blast – why not join us?

I’m pleased to announce that I’ll be teaching a week-long introductory Django course in Kansas City, September 21st - 25th.

Teaching’s folks how to use Django is one of my favorite things to do – in fact, I’m in San Jose right now gearing up for a tutorial at OSCON tomorrow – so it seemed a natural thing to make it an aspect of my business.

So, if you need to learn Django, why not come spend a week in Kansas City with me? It’ll be a blast.

Django’s session and authentication frameworks are designed to Just Work™, and can seem pretty magical. Like the rest of Django, though, these parts aren’t magic — just Python. So let’s take a look at the internals of sessions and authentication and see how the whole thing works.

Our journey begins with the session middleware. You’ll see that the process_request method is pretty simple: it looks up the session engine setting, looks for a session key in the request’s cookies, and then sets request.session to a SessionStore instance.

Need an experienced Python/Django developer?

A good friend of mine is looking for a new gig. He’s employed currently and wants to keep his search on the D/L, so I’m putting the word out on his behalf. I can vouch for this mysterious individual: I’d hire him myself in a heartbeat if I could. He’s got years of Django and Python experience, and a killer work ethic.

So if you’ve got a space on your team and would like to fill it with someone awesome let me know (jacob @ this domain) and I’ll put you two in touch.

Since it comes up a lot, I thought I’d spend a bit of time writing up my thoughts on what django.contrib really is, and what including a package in it really means.

The following is just my personal opinion – really; that’s why this is posted here instead of over in the official Django documentation. However, most of the core team discussed this topic at length at DjangoCon, so I’m fairly sure there’s consensus over the rough outline.

Almost four years ago, Adrian posted about a job opening at this little newspaper in the middle of the country. He wrote that

World Online is […] one of the most innovative online-news operations in the world. Our main sites […] have garnered an impressive batch of industry awards – and tremendous industry attention – over the past few years.

[…]

We strive for innovation, nimble development and the use of best practices. We have a near-religious focus on doing things the right way – clean URLs, CSS, separation of content from presentation, accessibility, solid application design, etc.

Paul Graham:

Arc only supports Ascii. MzScheme, which the current version of Arc compiles to, has some more advanced plan for dealing with characters. But it would probably have taken me a couple days to figure out how to interact with it, and I don’t want to spend even one day dealing with character sets. Character sets are a black hole. I realize that supporting only Ascii is uninternational to a point that’s almost offensive […] But the kind of people who would be offended by that wouldn’t like Arc anyway.”

A quick update on the Django Book:

Adrian and I wrapped up the last few bits last week, and the book went to the printer on Friday. It should start shipping to bookstores around the second week of December. There’s still a fair amount of work that needs to be done on the website, so I can’t put the final version of the book up just yet. However, the final book will be available online around the same time as the dead tree version.

I’ve always thought that the sign of a healthy Open Source project is a vibrant ecosystem around that project. That’s why I’ve been thrilled to see that there are a bunch of cool third-party Django add-ons popping up. I thought I’d take a few minutes and give a shout out to some of my favorites.

I’m extremely excited to announce our new internship program here in Lawrence. Starting this summer we’re going to be hiring interns to join our kick-ass team and learn the ropes.

If you’re a student, or if you’re trying to break into the world of next-generation web development, I can’t think of a better place to get started. You’ll get to spend up to six months developing cool toys (in Django, of course), live in one of the coolest towns in the country, and learn web development from the best.

So here’s a question I get asked a lot: “How big is Django’s community?”

Anyone who works in open source knows that it’s basically impossible to know the size of any open source community. It’s easy with commercial programs – just look at the sales numbers – but since F/OSS is freely (and widely) available, there’s almost no way to know how many people are using your project.

Still, the tie-wearing enterprisy business folks ask these types of questions, and it’s useful to have an answer ready. What follows is a slightly adapted version of my standard answer.

So it seems the BDFL Pronounced that Django is the Python web framework.

Obviously this makes me pretty damn happy. I’m sure this will help people trying to choose a web framework come to Django, and I think they’ll like what they find. Personally, I think Django’s the best tool to develop web sites – but of course I think that.

However, I want to make sure everyone has read Kevin Dangoor’s thoughts on the announcement. Kevin’s an awesome guy, a great programmer, and although I disagree with a few details here and there [1], the general gist is spot on.

Lately a large number of questions posted to django-users have included phrases like “this is a show-stopper” or “this is critical”. I think it’s worth my time to point out that this is a lousy method of getting developers to do what you want. It’s the online equivalent of threatening to take your ball and go home, and is about as effective.

I understand the impulse perfectly: there’s the fear that we won’t take you seriously if you don’t tell us just how important this is.

My last entry about my dog eating my DSlite hit Digg (screenshot), Reddit (screenshot), and a couple of other big-traffic sites over the weekend.

Pretty cool, but the coolest part is that my server — a single commodity Linux box that cost less than $3,000, running about 15 other sites — didn’t even hiccup.

Reason #4453 to use Django? It’s fast. Crazy fast.

Oh, and to all the Diggers who suggested that I should kill my dog? Fuck you and the horse you rode in on.

I just found this in my django-ego-feed: 23 excuses: Simple Django View for Dynamic Text Replacement

I’ve been using something similar to generate the titles for the site (look at the title above for an example), so I’m pretty familiar with the technique.

Andrew’s code over there is pretty good, but I’ve got a few improvements he and you might be interested in:

• The business to writing to a temp file is ugly and will break as soon as you get two simultaneous requests. The right way to do this is by remembering that an HTTPResponse exposes a file-like interface, so you can write the image directly to it:

I’m about to print up some Django shirts to take to OSCON next month – got any ideas?

We gotta move pretty fast (we’re going to try to get an order in to the printer this week) so if you’ve got any hot ideas (or designs, for that matter) send ’em to me!

I’ll mail anyone who gives an idea or a design one of the final shirts, but otherwise please don’t ask about “ordering” or otherwise “getting” one. If there are any left after OSCON I’ll make an announcement then, but this are intended for OSCON promotions.

Some Django propaganda:

Later this month, I’m speaking at the MySQL Users Conference in Santa Clara, and I’ll be in town the whole week.

I suspect there’s a good number of Django users living in the Bay Area (ha), and I’d like to meet as many of them as I can. Therefore, I propose that y’all let me buy you dinner. The details:

Brian Beck just announced that he’s beginning work on Merquery, a full-text indexer and search engine specifically designed for developers using RAD frameworks like Django.

I’m so excited about this I can barely contain myself. Right now Ellington ships with a search engine built on top of Swish-E. It’s pretty cool, and I’ve been debating cleaning it up and rolling it into django.contrib. However it has a number of major flaws that limit its usefulness:

For anyone looking for the Django stuff I showed off at PyCon:

• Slides from my presentation (PDF version [9 MB])
• The Sudoku app I demonstrated
• Source to the Sudoku app

Here’s a simple class for a template tag that caches its output (with apologies to Chris Parnell and Andy Samberg):

from django.core import template
from django.core.cache import cache
from django.conf.settings import DEBUG

class CachedNode(template.Node):
    """
    Cached template node.

    Subclasses should define the methods
    get_cache_key() and get_content() instead of the
    standard render() method. Subclasses may also
    define the class attribute cache_timeout to
    override the default cache timeout of ten minutes.
    """

    cache_timeout = 600

    def render(self, context):
        if DEBUG:
            return self.get_content(context)
        key = self.get_cache_key(context)
        content = cache.get(key)
        if not content:
            content = self.get_content(context)
            cache.set(key, content, self.cache_timeout)
        return content

    def get_cache_key(self, context):
        raise NotImplementedError

    def get_content(self, context):
        raise NotImplementedError

Inspired by Guido van Rossum’s plea to be taught web frameworks here are (in no particular order) ten reasons why he — and you — should use Django.

Yes, the Snakes and Rubies videos are now online.

No, they’re not perfect.

No, I’m not going to wait for FCP to re-render any more.

I’ll write a post-mortem after I’ve gotten some sleep; now go watch Adrian kick major ass.

After hearing some rave reviews of Dojo on django-dev, I finally got around to checking it out today. Here are my thoughts (with an obvious focus towards) using Dojo with Django).

Django handles lots of traffic with ease; Django sites have survived slashdottings, farkings, and more. Here are some notes on how we tweak our servers to get that type of high performance.

One of the questions asked at Snakes & Rubies was about what Django could learn from Rails (and vice versa). Once I finish wrestling Final Cut Pro to the ground you’ll be able to see how Adrian and David answered the question, but in the meantime it got me thinking about some cool features of Rails that are worth ripping off… er… being inspired by:

• find_or_create convenience methods. Pretty simple, so expect to see a similar method in Django pretty soon.

As I was going over some notes on our internal wiki, I ran across a list of rejected names for the framework that become Django:

• brazos
• superglue
• bodhisattva
• webbing
• boidae
• bohdi
• skoro
• consolidata
• piston
• physique
• silhouette
• valance
• anson
• The Python Web Framework (PWF)
• Tornado Publishing System
• Web Type Framework
• Pypeline
• super magic machine
• magic machine
• private dancer
• “the CMS”
• The Give-a-Damn machine
• boltdozer
• banister
• garbonzo
• Simon
• fizgig
• palmy
• cogent
• pith
• pithy
• pyth
• pythy
• festoon
• poeks
• lavalier
• clerisy
• bandwidth
• django

Sam Newman just posted a comparison of Django and Rails which is extremely balanced and fair, and a very good read. I’ve obviously got a few bits of feedback, so here goes: