Profiling Django applications – part2


Profiling using CProfile. Sometimes it is advantageous to look at what your application is doing before it goes in to production. Using tools like iPDB and PDB we can step through code, particularly in the view that you are working on, but it doesn’t tell the full picture of what is going on up-until that view is called, or after the HTTPResponse is starting to be returned. It is easy to start profiling django runserver using CProfile:

Profiling Django applications – part1


I have been doing some profiling of a Django application in different ways, and this is something that can be very useful to understand where bottlenecks are, why code behaves in certain ways and where we can trim the fat. There are multiple places where we can profile Django, and many of the pointers and resources from Python at large can be used when profiling Django. Things like Hotshot, cProfile and timeit are available, and there are helper libraries around these tools.

Celery ghetto queue


Currently wondering how the ghetto queue might work for smaller installations. I have done larger installations using RabbitMQ, celery’s preferred message mechanism, but for smaller loads and services running straight from django and postgres might be a good idea. I guess it maintains the flexibility of having an upgrade path but is less to install and maintain, thus being kinder to sysadmins and support staff. Going to try it I think.

Django Select Multiple filter.


Django has a really nice select multiple field, for choosing multiple items at once with a Javascript chooser.. It is really handy to use when there is a large number of items that have to be chosen from in a select. I am using with JQuery. To do this, grab SelectFilter2.js from the django-admin media folder, or get it from Django’s GitHub repository. Then to initialize it you can put the following into your code:

Django localization and internationalization

              · ·

We have been using the localization and internationalization ( l10n& i18n ) from Django quite a bit for our translations, and although we haven’t had to tackle anything difficult like Arabic or Persian yet there are still some shortcomings in the system. The standard Django module for input of dates and datetime stamps is quite restrictive. It depends on a module, I think written by Simon Willson which uses the PHP notation rather than the Python/C strftime / strptime notation.

Django 1.2 release


It was just announced that Django 1.2 will be released on May 17th, which is in 3 days time. Been waiting a while for this one to go to production release so I am really glad. The new messages framework looks much better, and I also love the date i18n features – something that really helps on a project at Cantemo where we have to deal with ISO formatted datetimes.

Python plugin systems


There is a lot of interesting information about creating plugin architectures using Python all over the web, but its in fairly disparate places. This is an overview of the documentation that I found as of April 2010. Firstly Dr André Roberge has some very interesting posts, as well as a talk at PyCon 2009 on entitled Plugins and monkeypatching: increasing flexibility, dealing with inflexibility. He is also the author of Crunchy which uses a plugin system.

Django on RedHat or CentOS

         · ·      · · ·

I am normally using Debian, Ubuntu or even Suse for deploying Django, but a recent customer needed to deploy on Red Hat Enterprise Server 5. We decided beforehand to test deployment on RHEL5 and also on CentOS 5.4 and so these instructions should work for both environments. NginX will be used as the webserver. The first thing I like to do is to upgrade the repository and add EPEL. This wasn’t needed I found on the RedHat box I was using, but was needed on CentOS but your mileage might vary.

Django staff member required


Here is a simple decorator that isn’t mentioned properly in the Django documentation. [cc lang=“python”]@staff_member_required[/cc] It basically checks to see if the user is logged in and has is_staff before allowing a user access to the view. Use like you would the normal @login_required decorator. [cc lang=“python”] from django.shortcuts import render_to_response from django.template.context import RequestContext from django.contrib.admin.views.decorators import staff_member_required @staff_member_required def my_view(request): return render_to_response(‘page.html’, context_instance=RequestContext(request)) [/cc]

Extending Django’s user admin


The built in admin pages that you get in Django can be useful, but they particularly become useful once you start to add a lot more functionality to them. For instance the Django’s User authentication system (which lives in django.contrib.auth ) is widely used, and quite often you need to extend the user’s profile by using AUTH_PROFILE_MODULE and a separate model. But having a separate Admin screen for this is kind of pointless.