Django community: Community blog posts RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
You Built a Metaclass for *what*?
Recently I had a bit of an interesting problem, I needed to define a way to represent a C++ API in Python. So, I figured the best way to represent that was one class in Python for each class in C++, with a functions dictionary to track each of the methods on each class. Seems simple enough right, do something like this: class String(object): functions = { "size": Function(Integer, []), }We've got a String class with a functions dictionary that maps method names to Function objects. The Function constructor takes a return type and a list of arguments. Unfortunately we run into a problem when we want to do something like this: class String(object): functions = { "size": Function(Integer, []), "append": Function(None, [String]) }If we try to run this code we're going to get a NameError, String isn't defined yet. Django models have a similar issue, with recursive foreign keys. Django's solution is to use the placeholder string "self", and have a metaclass translate it into the right class. Also having a slightly more declarative API might be nice, so something like this: class String(DeclarativeObject): size = Function(Integer, []) append = Function(None, ["self"])So now that we have a nice pretty … -
Getting Started with Testing in Django
Following yesterday's post another hotly requested topic was testing in Django. Today I wanted to give a simple overview on how to get started writing tests for your Django applications. Since Django 1.1, Django has automatically provided a tests.py file when you create a new application, that's where we'll start.For me the first thing I want to test with my applications is, "Do the views work?". This makes sense, the views are what the user sees, they need to at least be in a working state (200 OK response) before anything else can happen (business logic). So the most basic thing you can do to start testing is something like this: from django.tests import TestCase class MyTests(TestCase): def test_views(self): response = self.client.get("/my/url/") self.assertEqual(response.status_code, 200)By just making sure you run this code before you commit something you've already eliminated a bunch of errors, syntax errors in your URLs or views, typos, forgotten imports, etc. The next thing I like to test is making sure that all the branches of my code are covered, the most common place my views have branches is in views that handle forms, one branch for GET and one for POST. So I'll write a test like … -
Django and Python 3
Today I'm starting off doing some of the posts people want to see, and the number one item on that list is Django and Python 3. Python 3 has been out for about a year at this point, and so far Django hasn't really started to move towards it (at least at a first glance). However, Django has already begun the long process towards moving to Python 3, this post is going to recap exactly what Django's migration strategy is (most of this post is a recap of a message James Bennett sent to the django-developers mailing list after the 1.0 release, available here).One of the most important things to recognize in this that though there are many developers using Django for smaller projects, or new projects that want to start these on Python 3, there are also a great many more with legacy (as if we can call recent deployments on Python2.6 and Django 1.1 legacy) deployments that they want to maintain and update. Further, Django's latest release, 1.1, has support for Python releases as old as 2.3, and a migration to Python 3 from 2.3 is nontrivial. However, it is significantly easier to make this migration from Python … -
Why Meta.using was removed
Recently Russell Keith-Magee and I decided that the Meta.using option needed to be removed from the multiple-db work on Django, and so we did. Yesterday someone tweeted that this change caught them off guard, so I wanted to provide a bit of explanation as to why we made that change.The first thing to note is that Meta.using was very good for one specific use case, horizontal partitioning by model. Meta.using allowed you to tie a specific model to a specific database by default. This meant that if you wanted to do things like have users be in one db and votes in another this was basically trivial. Making this use case this simple was definitely a good thing.The downside was that this solution was very poorly designed, particularly in light on Django's reusable application philosophy. Django emphasizes the reusability of application, and having the Meta.using option tied your partitioning logic to your models, it also meant that if you wanted to partition a reusable application onto another DB this easily the solution was to go in and edit the source for the reusable application. Because of this we had to go in search of a better solution.The better solution we've … -
Splitting up Django models
Sometimes it makes sense to split up your Django models for a specific application across multiple files instead of having all of them in one models.py file. This allows for easier and simpler code organization and maintenance. Splitting up your models in Django is fairly simple, although it requires a few extra steps. In our example, [...] -
Django for a Rails Developer
This is not yet another Django vs Rails blog post. It is a compilation of notes I made working with Django after having worked on Rails for years. In this post I want to give a brief introduction to Django project layout from a Rails developer point of view, on what is there, what is [...] Related posts:Rails and Django commands : comparison and conversion The Rails and Django models layer Rosseta stone Tools of Pro Django developer – aka What powers dinette and almost every app we write. -
Filing a Good Ticket
I read just about every single ticket that's filed in Django's trac, and at this point I'e gotten a pretty good sense of what (subjectively) makes a useful ticket. Specifically there are a few things that can make your ticket no better than spam, and a few that can instantly bump your ticket to the top of my "TODO" list. Hopefully, these will be helpful in both filing ticket's for Django as well as other open source projects.Search for a ticket before filing a new one. Django's trac, for example, has at least 10 tickets describing "Decoupling urls in the tutorial, part 3". These have all been wontfixed (or closed as a duplicate of one of the others). Each time one of these is filed it takes time for someone to read through it, write up an appropriate closing message, and close it. Of course, the creator of the ticket also invested time in filing the ticket. Unfortunately, for both parties this is time that could be better spent doing just about anything else, as the ticket has been decisively dealt with plenty of times.On a related note, please don't reopen a ticket that's been closed before. This one depends … -
Javascript inline forms outside of contrib.admin
This recipe follows on from the last two and shows how to do the addition of inline fields to a model form, outside of contrib.admin. -
What apps do I use?
I've been asked by a few people what apps am I going to use for this website. I'll probably go into some of them in a bit more detail at some point. However, I thought for those that are interested I would quickly dump my pip requirements.txt here. Django==1.1.1 Markdown==2.0.3 MySQL-python==1.2.3c1 #PIL==1.1.6 Pygments==0.10 South==0.6.2 Sphinx==0.5.2 django-tagging==0.3 docutils==0.5 oauth==1.0.1 simplejson==2.0.9 sorl-thumbnail==3.2.5 textile==2.1.3 twisted wsgiref==0.1.2 html5lib==0.11.1 pisa==3.0.32 django-debug-toolbar==0.8.1 django-vcs==0.1 django-disqus==0.2 http://effbot.org/downloads/Imaging-1.1.6.tar.gz http://www.reportlab.org/ftp/ReportLab_2_3.tar.gz -e git+git://github.com/dustin/twitty-twister.git#egg=twittywtister -e git+git://github.com/montylounge/django-basic-apps.git#egg=basic That gives you quite a good idea about what I'm using. It also maybe gives away some of the features I'm planning... well, a hint or two perhaps! -
A Bit of Benchmarking
PyPy recently posted some interesting benchmarks from the computer language shootout, and in my last post about Unladen Swallow I described a patch that would hopefully be landing soon. I decided it would be interesting to benchmarks something with this patch. For this I used James Tauber's Mandelbulb application, at both 100x100 and 200x200. I tested CPython, Unladen Swallow Trunk, Unladen Swallow Trunk with the patch, and a recent PyPy trunk (compiled with the JIT). My results were as follows:100CPython 2.6.4 17sUnladen Swallow Trunk 16sUnladen Swallow Trunk + Patch 13sPyPy Trunk 10s200CPython 2.6.4 64sUnladen Swallow Trunk 52sUnladen Swallow Trunk + Patch 49sPyPy 46sInteresting results. At 100x100 PyPy smokes everything else, and the patch shows a clear benefit for Unladen. However, at 200x200 both PyPy and the patch show diminishing returns. I'm not clear on why this is, but my guess is that something about the increased size causes a change in the parameters that makes the generated code less efficient for some reason.It's important to note that Unladen Swallow has been far less focussed on numeric benchmarks than PyPy, instead focusing on more web app concerns (like template languages). I plan to benchmark some of these as time goes on, … -
Writing your own template loaders
Django has three builtin template loaders which are used to get the templates for rendering. TEMPLATE_LOADERS = ( 'django.template.loaders.filesystem.load_template_source', 'django.template.loaders.app_directories.load_template_source', # 'django.template.loaders.eggs.load_template_source', ) Writing your template loader is a awfuly easy. It is a callable which Returns a tuple of (openfile, filename) if it can find the template. Raise TemplateDoesNotExist if the templates cannot be [...] Related posts:A response to Dropping Django -
Things College Taught me that the "Real World" Didn't
A while ago Eric Holscher blogged about things he didn't learn in college. I'm going to take a different spin on it, looking at both things that I did learn in school that I wouldn't have learned else where (henceforth defined as my job, or open source programming), as well as thinks I learned else where instead of at college.Things I learned in college:Big O notation, and algorithm analysis. This is the biggest one, I've had little cause to consider this in my open source or professional work, stuff is either fast or slow and that's usually enough. Learning rigorous algorithm analysis doesn't come up all the time, but every once in a while it pops up, and it's handy.C++. I imagine that I eventually would have learned it myself, but my impetus to learn it was that's what was used for my CS2 class, so I started learning with the class then dove in head first. Left to my own devices I may very well have stayed in Python/Javascript land.Finite automaton and push down automaton. I actually did lexing and parsing before I ever started looking at these in class (see my blog posts from a year ago) using … -
Another Pair of Unladen Swallow Optimizations
Today a patch of mine was committed to Unladen Swallow. In the past weeks I've described some of the optimizations that have gone into Unladen Swallow, in specific I looked at removing the allocation of an argument tuple for C functions. One of the "on the horizon" things I mentioned was extending this to functions with a variable arity (that is the number of arguments they take can change). This has been implemented for functions that take a finite range of argument numbers (that is, they don't take *args, they just have a few arguments with defaults). This support was used to optimize a number of builtin functions (dict.get, list.pop, getattr for example).However, there were still a number of functions that weren't updated for this support. I initially started porting any functions I saw, but it wasn't a totally mechanical translation so I decided to do a little profiling to better direct my efforts. I started by using the cProfile module to see what functions were called most frequently in Unladen Swallow's Django template benchmark. Imagine my surprise when I saw that unicode.encode was called over 300,000 times! A quick look at that function showed that it was a perfect … -
Announcing django-admin-histograms
This is just a quick post because it's already past midnight here. Last week I realized some potentially useful code that I extracted from the DjangoDose and typewar codebases. Basically this code let's you get simple histogram reports for models in the admin, grouped by a date field. After I released it David Cramer did some work to make the code slightly more flexible, and to provide a generic templatetag for creating these histograms anywhere. The code can be found on github, and if you're curious what it looks like there's a screenshot on the wiki. Enjoy. -
Continous sphinx build
I have always found the cycle : Edit the documentation source => build the sphinx based documentation [1] => open a browser pointing the updated documentation and re iterate until your are satisfied a bit painful.Today I have finally found an automated version of this workflow that gave me one of this nice WAHOUUUU feeling that happens after you remove this little stone from your shoe.The idea is to continuously build the documentation using watch [2]watch -n 2 make htlmThis will update the generated documentation every 2 seconds. This is nice in itself and it leads me to discover that Epiphany automatically reload the page when it changes.[1] http://sphinx.pocoo.org/[2] http://linux.die.net/man/1/watch[3] http://projects.gnome.org/epiphany/ -
Hooking into django's login and logout - two approaches
Hooking into django's authentication system using two approaches: a custom authentication_backend and signals. -
Запускаем progopedia.com
Запускаем англоязычную версию Прогопедии — свободной энциклопедии языков программирования — progopedia.com. Сайт еще в стадии альфа-версии, не хватает описаний многих популярных языков программирования, движок определенно требует доработки — но для начала неплохо, я думаю. Сайт использует Django (естественно), Markdown (при помощи http://pypi.python.org/pypi/Markdown/) в качестве языка разметки, Pygments для подсветки синтаксиса, django-reversion для контроля версий, DISQUS и django-disqus для комментариев. Отзывы и комментарии приветствуются. Кто хочет присоединиться к progopedia.com в качестве редактора — присоединяйтесь :-) -
My Next Blog
I've been using this Blogspot powered blog for over a year now, and it is starting to get a little long in the tooth. Therefore I've been planning on moving to a new, shinny, blog of my own in the coming months. Specifically it's going to be my goal to get myself 100% migrated over my winter break. Therefore I've started building myself a list of features I want:Able to migrate all my old posts. This isn't going to be a huge deal, but it has to happen as I have quite a few posts I don't want to lose.Accepts restructured text. I'm sick of writing my posts in reST and then converting it into HTML for Blogspot.Pretty code highlighting.Disqus for comments. I don't want to have to deal with spam or anything else, let users post with Disqus and they can deal with all the trouble.Looks decent. Design is a huge weak point for me, so most of my time is going to be dedicated to this I think.Django powered!That's my pony list thus far. There's a good bet I'll use django-mingus since I've hear such good things about it, but for now I'm just dreaming of being able … -
Adding Javascript to contrib.admin inline fields
This recipe follows on from the last by adding Javascript to the inline fields of a model in the contrib.admin. -
Changes afoot at Django-NYC
Recently Justin Lilly and I have taken up the day-to-day running of the Django-NYC users group to take some load off its original founders, Loren Davie and Kevin Fricovsky. Loren and Kevin have done a great job of getting the group off the ground and building a community around Django in NYC. Unfortunately, as with most user groups, running [...] -
South – incredible easy migrations for Django
I’ve been hacking away at a side project for the past three or four weeks – got myself to internal milestone #2 this weekend, for which I’m really pleased. The very tail end of this milestone was deploying the code … Continue reading → -
Setup Python 2.6.4, mod_wsgi 2.6, and Django 1.1.1 on CentOS 5.3 (cPanel)
This is an update to my previous how-to Setup Python 2.5, mod_wsgi, and Django 1.0 on CentOS 5 (cPanel). The biggest reason why I chose to go with Python 2.5 at the time was because the MySQL Python (MySQLdb) package didn't support Python 2.6. The 1.2.3c1 release does so that roadblock is lifted. The instructions [...] Related posts:Setup Python 2.5, mod_wsgi, and Django 1.0 on CentOS 5 (cPanel) Ruby On Rails and SliceHost Part 1: Initial Setup Getting Started with Django and Python – First Impressions -
Why jQuery shouldn't be in the admin
This summer as a part of the Google Summer of Code program Zain Memon worked on improving the UI for Django's admin, specifically he integrated jQuery for various interface improvements. I am opposed to including jQuery in Django's admin, as far as I know I'm the only one. I should note that on a personal level I love jQuery, however I don't think that means it should be included in Django proper. I'm going to try to explain why I think it's a bad idea and possibly even convince you.The primary reason I'm opposed is because it lowers the pool of people who can contribute to developing Django's admin. I can hear the shouts from the audience, "jQuery makes Javascript easy, how can it LOWER the pool". By using jQuery we prevent people who know Javascript, but not jQuery from contributing to Django's admin. If we use more "raw" Javascript then anyone who knows jQuery should be able to contribute, as well as anyone who knows Mootools, or Dojo, or just vanilla Javascript. I'm sure there are some people who will say, "but it's possible to use jQuery without knowing Javascript", I submit to you that this is a bad … -
Setting up a django project with Cherokee, uWSGI and vitualenv (continued)
In my previous post [1] I have started to talk about this stack but I have avoided to mention that the django project was indeed encapsulated into a virtualenv. This brought a couple small quirks and questions to the surface. So I spent some times investigating and exchanging with the community behind uWSGI and cherokee in order to solve them. The enhancements I discuss here require that you use the tip of uWSGI [2] because some of them are new capability added in the past days or small improvements to my recipe of using these products.Before I start to dive into the enhancements let me sum up what we had to do in order to serve our WSGI project, in our case a django project.1> I had to add 2 configurations files : uwsgi.conf, django_wsgi.pyThe first one is an XML file where you define the PYTHONPATH and the mount point for your application, the second one is a python module where you define your WSGI configuration.2> I had to use the cherokee's wizard to create the appropriate configuration to serve my django app using uWSGI. This step add an "Information Sources" with the following settings in the interpreter section :/usr/local/bin/uwsgi … -
You need an editor
I’m supposed to be this expert on writing, right? So how come my previous articles have had so many errors? Simple: my blog doesn’t have an editor. That’s typical for a blog, but it’s unfortunately also typical of open source documentation: the vast majority of technical documentation doesn’t reach far beyond rough draft status. All good writers have a dirty little secret: they’re not really that good at writing. Their editors just make it seem that way.