Weblog

July archive

Introducing Django 0.95

July 29, 2006

We're pleased to introduce Django release 0.95, a formal packaging of all of the significant advances in Django development since the 0.91 release in January 2006.

This is the sexiest version of Django ever. It would take another six months to list all of the improvements, feature additions and bug fixes we've put into this release, but the release notes document attempts to list the big changes. The overall theme is: Slicker, faster, easier, better.

Notably, this release includes the "magic-removal" changes that were made to Django's development ("trunk") version a few months ago. If you're upgrading from Django 0.91 to 0.95, you'll need to make some changes to your code, because several APIs have changed. See the RemovingTheMagic wiki page for full instructions, and feel free to ask questions on the django-users mailing list; if you have a problem, chances are somebody else has had it and solved it.

With those API changes in mind, we've written a new document, API stability, that explains which APIs should be considered stable and which ones will likely change before 1.0. The good news is that most (80 percent?) of Django's APIs are set in stone at this point. Once we get to version 1.0, of course, all APIs will be stable.

Also forthcoming is a roadmap to Django's next version, 0.96, which we're hoping to churn out sooner rather than later. It'll incorporate some improvements to model subclassing and validation-aware models, along with other features. Look for that roadmap in the next few days.

Thanks, as always, to the dozens of Django contributors around the world. We try (but inevitably fail) to list everybody in the AUTHORS file.

So, what are you waiting for? Download it, and let us know what you think!

Django at OSCON

July 19, 2006

Jacob and Adrian will be at OSCON next week. We've got a few cool things planned:

  • Jacob will be giving a Django tutorial on Monday. Watch this blog for a link to the slides and handouts after OSCON.
  • Wednesday afternoon is the main Django session. We'll talk about the history of Django, its core philosphies, and some of the cool features you probably already know all about.
  • That evening at 7:30 is the Django meet-n-greet. We'll hang out, discuss horror stories, and give away free Django swag (don't miss it!).

If you'll be at OSCON, come say hi!

Performance test results

July 14, 2006

Some folks benchmarked three Web frameworks: Symfony (PHP), Ruby on Rails and Django. They found Django to be the fastest:

Rails performed much better than Symfony. And Django performed much better than Rails.

Granted, the nature of Web frameworks makes it difficult to make this an apples-to-apples test. But, as the benchmarkers themselves say, "We feel these results, though not the whole picture, offer hints about relative performance between the three frameworks/platforms."

To be honest, these results doesn't come as a surprise to us Django developers. We've been performance-conscious from the very start, and performance concerns guide us at every level -- from the template system to URL parsing to database access. (A good example of how performance-crazy we are is the new USE_I18N setting, unveiled last week, which turns off internationalization overhead if you're not using it.)

Get the word out! How about posting this to del.icio.us and Digging it?

Interview on Rails podcast

July 14, 2006

I'm not quite sure how we got away with this, but the Ruby on Rails podcast interviewed yours truly about Django in Chicago a couple of weeks ago. They just posted the interview.

Weeks in review: July 10

July 10, 2006

Here are the highlights of Django improvements over the past couple of weeks.

  • Changeset 3214: Added title_template and description_template hooks to Feed class in syndication framework. These let you override the default template names for Feed classes, which is useful when you've got multiple Feed classes with the same slug.
  • Changeset 3217: Added Manager.create() method, which creates and saves an object in a single step. This is nicely parallel to the API for creating related objects (e.g. foo.site_set.create()) and lets you do more in fewer lines of code.
  • Changeset 3223: Date lookups/comparisons using the database API now accept strings as well as datetime objects. For example, Article.objects.filter(pub_date__exact='2005-07-27') is now valid. Previously, you had to pass in a datetime object.
  • Changeset 3225, 3237 and others: Added a serialization framework, which includes JSON output. Expect more on this soon.
  • Changeset 3226: Merged the "multi-auth" branch to trunk. This makes Django's authentication layer pluggable. For instance, you can plug in LDAP or some other authentication source. See the new docs. Big thanks to Joseph Kocherhans for his work on this.
  • Changeset 3246: Raw objects can now be used as database lookup values in "exact" and "in" query lookups. For example, now Article.objects.filter(author=some_author_instance) is possible, rather than Article.objects.filter(author__id__exact=some_author_instance.id).
  • Changeset 3247: Added a USE_I18N setting, which lets you turn off internationalization overhead with a single setting. It defaults to True for backwards compatibility. If you set USE_I18N=False, your admin JavaScript will be more efficient/lightweight, and Django won't load most internationalization code into memory. More optimizations are forthcoming.
  • Changeset 3248: Now any database lookup argument that doesn't end in a known query term (such as "exact", "lt", "contains", etc.) is assumed to be "exact". This means you can use Photo.objects.filter(author__name='John') rather than Photo.objects.filter(author__name__exact='John').
  • Changeset 3269: The template system now treats literal strings 'False' and 'True' as the boolean equivalents.
  • Changeset 3272: Added an optional argument to the "pluralize" template-system filter, which lets you specify the pluralization for words that aren't pluralized by adding a simple "s".
  • Changeset 3285: Improved the SQLite database introspection (django-admin.py inspectdb) to find primary keys.
  • Changeset 3305: The e-mail validator now accepts top-level domains of up to six characters long, to accomodate the new ".museum" domain.
  • Changeset 3307: Added a list_display_links option to class Admin. This regulates which fields/columns on the admin change-list page have links. See the docs.

In other Django news: