Isso me aconteceu a pouco e eu não vi resultados no google para o erro em específico, então estou eu aqui fazendo minha parte .

Caso você ver o erro abaixo e tiver rodando reversion 1.5 + django 1.2.x, você precisa instalar alguma versão menor que a 1.5 do reversion, pois a 1.5 só suporta django 1.3 (veja tabela de versões aqui).

Segue a exception:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

[Tue Sep 27 10:19:17 2011] [error] MyLDAPUser->AUTHENTICATE: felipe.rafael@pdg.com.br authenticated :D
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79] mod_wsgi (pid=14847): Exception occurred processing WSGI script '/var/www/qas3/portal/apache/virtualenv-qas3.wsgi'.
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79] Traceback (most recent call last):
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]   File "/opt/python2.6/lib/python2.6/src/django/django/core/handlers/wsgi.py", line 252, in __call__
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]     response = middleware_method(request, response)
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]   File "/opt/python2.6/lib/python2.6/site-packages/reversion/middleware.py", line 20, in process_response
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]     reversion.revision.end()
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]   File "/opt/python2.6/lib/python2.6/site-packages/reversion/revisions.py", line 301, in end
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]     comment = self._state.comment,
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]   File "/opt/python2.6/lib/python2.6/src/django/django/db/models/manager.py", line 138, in create
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]     return self.get_query_set().create(**kwargs)
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]   File "/opt/python2.6/lib/python2.6/src/django/django/db/models/query.py", line 358, in create
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]     obj.save(force_insert=True, using=self.db)
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]   File "/opt/python2.6/lib/python2.6/src/django/django/db/models/base.py", line 458, in save
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]     self.save_base(using=using, force_insert=force_insert, force_update=force_update)
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]   File "/opt/python2.6/lib/python2.6/src/django/django/db/models/base.py", line 551, in save_base
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]     result = manager._insert(values, return_id=update_pk, using=using)
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]   File "/opt/python2.6/lib/python2.6/src/django/django/db/models/manager.py", line 195, in _insert
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]     return insert_query(self.model, values, **kwargs)
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]   File "/opt/python2.6/lib/python2.6/src/django/django/db/models/query.py", line 1524, in insert_query
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]     return query.get_compiler(using=using).execute_sql(return_id)
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]   File "/opt/python2.6/lib/python2.6/src/django/django/db/models/sql/compiler.py", line 788, in execute_sql
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]     cursor = super(SQLInsertCompiler, self).execute_sql(None)
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]   File "/opt/python2.6/lib/python2.6/src/django/django/db/models/sql/compiler.py", line 732, in execute_sql
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]     cursor.execute(sql, params)
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]   File "/opt/python2.6/lib/python2.6/src/django/django/db/backends/util.py", line 15, in execute
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]     return self.cursor.execute(sql, params)
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]   File "/opt/python2.6/lib/python2.6/src/django/django/db/backends/mysql/base.py", line 86, in execute
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]     return self.cursor.execute(query, args)
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]   File "/opt/python2.6/lib/python2.6/site-packages/MySQLdb/cursors.py", line 176, in execute
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]     if not self._defer_warnings: self._warning_check()
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]   File "/opt/python2.6/lib/python2.6/site-packages/MySQLdb/cursors.py", line 92, in _warning_check
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79]     warn(w[-1], self.Warning, 3)
[Tue Sep 27 10:19:17 2011] [error] [client 192.168.20.79] Warning: Field 'manager_slug' doesn't have a default value

Existem por ai dezenas de artigos e snippets sobre como trabalhar com JSON
em Django, entretanto vi que a maioria é um pouco vaga e a solução envolve serializar com simplejson e mandar para o HttpResponse. Existem alguns detalhes que normalmente não se cobrem e eu apresento a maneira fácil de trabalhar e um exemplo funcional de JSON em um formulário.

:: Problemas comuns ::

Os problemas mais comuns que vejo ao trabalhar com JSON em qualquer lugar e não só em Django são:

1. Nem sempre é simples parsear os argumentos enviados
2. O simplejson da problemas com alguns tipos de objetos
3. Porque não termos um JSONResponse em vez de somente o HttpResponse ?

:: A solução ::

1. Criar um JSON serializer que manipula objetos que dão problema ao simplejson.dumps
2. Criar a JSONResponse, baseada na HttpResponse e no nosso novo serializer
3. Achar um meio fácil de parsear os argumentos enviados para obter o JSON

A JSONResponse usa o JSON serializer e retorna uma response com os parâmetros enviados pela view. Os parâmetros são os objetos a serem serializados.

Definido isso vamos criar uma APP Django chamada jsonui . Ela tera 2 models, cidade e estado, 2 views, a main e a que retorna o json, um form simples e os arquivos response.py e utils.py com os métodos que usaremos para gerar o JSON bonitinho.

:: O JSON serializer ::

O serializer reside no utils, ele é divido em um JSONEncoder usado pelo simplejson que é responsável por interpretar os objetos que dariam problema, e no serializer propriamente dito que nada mais é um wrapper pro simplejson:

Arquivo: jsonui/utils.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

# -*- coding: utf-8 -*-
 
from django.utils import simplejson
from django.utils.encoding import force_unicode
from django.db.models.base import ModelBase
 
class LazyJSONEncoder(simplejson.JSONEncoder):
    """ a JSONEncoder subclass that handle querysets and models objects.
    Add how handle your type of object here to use when when dump json"""
    def default(self,o):
        # this handles querysets and other iterable types
        try:
            iterable = iter(o)
        except TypeError:
            pass
        else:
            return list(iterable)
 
        # this handlers Models
        try:
            isinstance(o.__class__,ModelBase)
        except Exception:
            pass
        else:
            return force_unicode(o)
 
        return super(LazyJSONEncoder,self).default(obj)
 
def serialize_to_json(obj,*args,**kwargs):
    """ A wrapper for simplejson.dumps with defaults as:
 
    ensure_ascii=False
    cls=LazyJSONEncoder
 
    All arguments can be added via kwargs
    """
 
    kwargs['ensure_ascii'] = kwargs.get('ensure_ascii',False)
    kwargs['cls'] = kwargs.get('cls',LazyJSONEncoder)
 
 
    return simplejson.dumps(obj,*args,**kwargs)

:: A JSONResponse ::

A JSONResponse reside no response, basicamente ela recebe a lista, dicionário ou qualquer objeto que você envia para o JSONResponse e retorna serializado:

Arquivo: jsonui/response.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# -*- coding: utf-8 -*-
 
from utils import serialize_to_json
from django.http import HttpResponseForbidden, HttpResponse
 
class JSONResponse(HttpResponse):
    """ JSON response class """
    def __init__(self,content='',json_opts={},mimetype="application/json",*args,**kwargs):
        """
        This returns a object that we send as json content using 
        utils.serialize_to_json, that is a wrapper to simplejson.dumps
        method using a custom class to handle models and querysets. Put your
        options to serialize_to_json in json_opts, other options are used by
        response.
        """
        if content:
            content = serialize_to_json(content,**json_opts)
        else:
            content = serialize_to_json([],**json_opts)
        super(JSONResponse,self).__init__(content,mimetype,*args,**kwargs)

:: Botando pra funcionar na view. ::

Sem mais rodeios, vamos ver como funciona. Nós temos duas views:

• mainview: chama o form e renderiza um template com o código javascript necessário para executar o POST e renderizar o JSON que obtemos como resposta.
• json_get_city: responsável por retornar as cidades de acordo com o estado enviado.

Arquivo: urls.py @ 17

17
18

(r'^$','jsonui.views.mainview'),
(r'^ajax/city/','jsonui.views.json_get_city'),

Arquivo: jsonui/views.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# -*- coding: utf-8 -*-
 
from django.shortcuts import render_to_response
from django.template import RequestContext
 
 
from models import City,State
from forms import CityForm
 
from utils import qdct_as_kwargs
from response import JSONResponse
 
def mainview(request):
 
    return render_to_response('base.html',{'form': CityForm() },
        context_instance=RequestContext(request))
 
def json_get_city(request):
 
    if not request.method == "POST":
        # return all cities if any filter was send
        return JSONResponse(City.objects.order_by('name'))
 
    # get cities with request.POST as filter arguments
    cities = City.objects.filter(**qdct_as_kwargs(request.POST)).order_by('name')
 
    #return JSONResponse with id and name
    return JSONResponse(cities.values('id','name'))

O método qdct_as_kwargs é responsável por retornar um dicionário que é passado parao método filter de um objeto a partir do request.POST ou request.GET. É uma magica legal que agiliza e muito a criação de views como essa.

Assim que a url /ajax/city/ recebe o POST ela obtem as cidades usando o qdct_as_kwargs e retorna a JSONResponse, no javascript a resposta é um JSON pronto para usar.

Arquivo: jsonui/utils.py @ 44

44
45
46
47
48

def qdct_as_kwargs(qdct):
kwargs={}
for k,v in qdct.items():
    kwargs[str(k)]=v
return kwargs

O javascript responsável por mandar o POST esta no template base.html que é renderizado pela mainview. Este é o trecho relevante:

Arquivo: templates/base.html @ 10

10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

$(function(){
    $("#id_state").change(function(e){
        $.post(
            // url to post
            "/ajax/city/",
            // args
            {state__id:$(this).val()},
            // response callback
            function(data,text,xhrobject){
                // uncomment if you wanna to see objects on firebug console
                //console.log(data,text,xhrobject)
                $("#id_city").children().remove()
                    .append("<option selected=\"selected\" value=\"\">------</option>")
                for (i in data) {
                    i = data[i]
                    $("#id_city").append(
                        "<option value=\""+i.id+"\">"+i.name+"</option>"
                    )
                }
            })
    })
})

Este código executa um POST para /ajax/city/ e na volta preenche o select de cidades com o objeto retornado.

:: Finalizando ::

Reproduzindo javascripts similares e usando o qdct_as_kwargs e o JSONResponse como usado na view json_get_city você pode facílmente criar várias views ou até uma view mais genérica que pegue de qualquer modelo. Basta deixar a imaginação fluir .

Você pode baixar o projeto completo aqui: jsonproject.tbz2 (MD5 Hash) (mirror, mirror MD5)

Eu construi ele usando Django 1.2, mas roda em qualquer versão acima da 1.0.

Divirta-se, contribua, comente

Abraços!

** UPDATES

• Se você está ganhando erros 403, cheque permissões na view ajax e o CSRF (dica por Nick Young)
• Se você precisa de dados adicionais na resposta JSON veja a ajuda que dei ao Jim

Este fim de semana eu reescrevi meu .vimrc e gastei um tempo extra para fazer
as coisas funcionarem melhores para mim com python e django . Eu acabei
fazendo um belo trabalho e agora estou codando com muito mais eficiência.

Os resultados são:

• Um .vimrc muito bem comentado e com muitas customizações.
• Suporte para python omnicomplete.
• Adição dos paths python e django automáticos ao ambiente do vim.
• Adição da DJANGO_SETTINGS_MODULE automaticamente ao ambiente do vim, para completar seu próprio código.
• Suporte do SnipMate para código django e django templates.
• Django templates com suporte para highlighting das tags e uso do ‘%’ com o plugin matchit.
• Python folding e suporte a python jumping.
• O tema acinzentado wombat com algumas customizações minhas.
• Um gerenciador de sessões para o Vim para facilitar sua vida em manter o ambiente de trabalho.

Aqui estão os arquivos para download:

• vim-confs-latest.tbz2: O arquivo tar compactado com todos os arquivos, descompacte na sua home.
• vim-confs-latest.tbz2.md5: O md5sum do tar.

Se você preferir, este é o endereço no github: http://github.com/chronossc/my-vim-confs

O pacote não poderia ter sido criado sem alguns plugins e artigos, segue a referência:

• UsingVimWithDjango do Django Wiki
• SnipMate vim plugin por Michael Sanders
• SnipMate snippets for django por Rob Hudson (Demo)
• Matchit vim plugin por Benji Fisher
• Updated Syntax highlighting for Django templates por Dave Hodder
• py_jump vim plugin por Sergiy Matusevych
• python fold vim plugin por Jorrit Wiersma
• Session Manager for vim por Yuri Klubakov

Adicionalmente (thx Handrus), eu sugiro para quem escreve muito HTML, dar uma olhada no SparkUp vim and textmate plugin . Eu não testei, mas pareceu muito bom.

Muito obrigado a quem ler, a todos que escreveram os plugins, ao pessoal do canal #vim na freenode e a ótima documentação do vim!
Agora bora codar com o vim

** Atualizado
2010-03-07: Eu criei novamente o tar porque eu removi algumas mensagens de debug, então faça o download novamente se você já fez .
2010-03-09: Eu criei novamente o tar, fiz alguns fixes e adicionei no github.

Múltiplos ambientes python

Trabalhar com várias versões de ambientes python tem se tornado algo comum em minha vida, e acredito que um meio fácil de ‘setar’ estes ambientes seja algo útil e não tão simples para a maioria das pessoas.

Eu criei um simples bash script que seta este ‘ambiente’, trata-se de uma função que você cria no seu .bash_profile. Executa-se ela com a versão do python em seguida e pronto, seu ambiente esta configurado. Vamos ver no código como eu fiz, o script está com comentários em inglês:

export ORIGINALPATH=$PATH
loadpyenv(){
    # $PV is our control variable, get from $1, first argument on shell
    # anything that you need to put here and depend for python version ${PV} is your var ;)
    export PV=$1
    echo -e "\n:: Setting environ to use python $PV"
 
    # Put here various aliases that you can use
    # put a python alias
    alias python="python${PV}"
    # m and runserver a kick alias for Django common actions
    alias m="python${PV} manage.py"
    alias runserver="python${PV} manage.py runserver :8000"
    # easy and fast install of python packages, in right path with localpyinstall
    alias localpyinstall="python${PV} setup.py install --prefix=~/.py/${PV}/"
    echo -e "\n:: New aliases"
    # print aliases :)
    alias python m runserver localpyinstall
 
    echo -e "\n:: New PATH"
    # setup aplications path, be careful about not use $ORIGINALPATH.
    #
    # I use a path structure like that:
    # ~/.py/
    # |-- 2.4
    # |-- 2.5
    # `-- 2.6
    export PATH="${HOME}/.py/${PV}/bin/:${ORIGINALPATH}"
    echo $PATH
    echo -e "\n:: New PYTHON PATH"
    # setup new python path, don't need to add system wide path, just our custom paths
    export PYTHONPATH="${HOME}/.py/${PV}/lib/python${PV}/site-packages/"
    # print more some info
    python$PV -c "import sys;print sys.path"
    echo -e "\n:: Django version & file"
    python$PV -c "import django;print 'version %s ... file %s' % (django.get_version(),django.__file__);"
}

Agora crie uma estrutura de diretórios com o comando:

$ mkdir -pv ~/.py/{2.4,2.5,2.6}

E cada vez que for usar uma versão diferente do python, carregue com:

$ loadpyenv VERSÃO

Onde VERSÃO é a versão escolhida do python.

Várias versões do Python no Gentoo

O Gentoo Linux, minha distro do dia a dia, me dá um bom bonus quanto a múltiplas versões do python, configure no /etc/make.conf a seguinte linha:

USE_PYTHON="2.4 2.5 2.6"

Instale os pythons nas versões escolhidas e execute o seguinte comando para re-compilar seus pacotes:

emerge $(eix -I dev-python/* | grep "\[I\]" | cut -d' ' -f2)

O eix é uma aplicação de indexação do portage, muito comum nas máquinas Gentoo.

Cada pacote python é recompilado para as 3 versões (no caso), mas tive problemas em compilar alguns pacotes para a 2.4, fiquem avisados

Bom, é isso, até mais!

Olá pessoal . Recentemente, precisei usar o módulo Auth do Django e suas permissões. É bastante interessante como você pode definir permissões por módulo e usar nas views, templates, etc.

Nosso código de hoje vem da necessidade de trabalhar facilmente com permissões negadas, onde o Django fornece apenas um HttpResponseForbidden, o que não é exatamente interessante de manipular, pois o ideal seria algo como a manipulação de erros 404.

Com essa necessidade desenvolvi um Middleware que intercepta exceções Http403 (vem junto com o pacote), e retorna uma das seguintes opções, na ordem de prioridade:

1. Uma view customizada, configurada usando handler403 no seu urls.py
2. Renderiza o template 403.html
3. Renderiza um template Hardcoded

Para usar o Middleware, siga os procedimentos:

1. Baixe o projeto no fim deste post, vamos usa-lo de exemplo, ele se chama http403project.
2. Descompacte e copie o arquivo http.py para algum lugar do seu projeto, no http403project ele fica na raiz.
3. Adicione o middleware ao settings.py:

   MIDDLEWARE_CLASSES = (
         # ...
         'http403project.http.Http403Middleware',
   )

4. De raise na view, ex:

   from http import Http403
   def Http403View(request):
     raise Http403(u"This is custom message for permission denied.")

5. Configure sua view customizada ou template se desejar. Seu template deve ter o nome de 403.html, sua view recebe os argumentos request e exception, o argumento exception contem a mensagem enviada pelo usuário . No projeto exemplo ele está renderizando o template 403.html, mas existe uma view de exemplo bastante simples no arquivo urls.py

Projeto: http403project.tgz

Ok, é isto, super simples, por hoje é só , divirtam-se!

Hoje vi um post num dos blogs que acompanho, onde um camarada disse ter conseguido 1000% de melhora na performance de uma aplicação trocando um:

SELECT * FROM TABLE WHERE fieldname ILIKE 'abc%';

Para

SELECT * FROM TABLE WHERE LOWER(fieldname) LIKE 'abc%';

(diferença de ilike para lower… like)
Eu achei tosco (hehehe), óbviamente que esse ganho absurdo só pode ter ocorrido numa massa gigantesca de dados e provavelmente num campo sem índice.
Mas a minha dica é outra:
Além do ganho em performance o “ilike” não é suportado no mysql e sqlite.Portanto seu uso é extremamente desaconselhável, principalmente se você estiver trabalhando com Django, Rails ou qualquer aplicação que forneça um layer multi-db.
Claro que nos frameworks citados acima o único jeito de fazer isso é forçar o uso de “ilike”, suas ORMs conseguem lidar com situações assim muito bem.

Conclusão
Evite “ilike” em queries de sql, use o “lower()… like” ou “upper… like”; E se lembre de mudar sua variável para upper/lower!

1 – Browsers

Firefox 3.5, chrome, opera, avant browser.  – Não faz sentido IE se você já está num windows certo? E ainda que você precise de outras versões lembre-se que estou falando de licenças free. A microsoft ainda não liberou nenhuma versão portable.

2 – Editores/IDEs

Aptana – apenas escolha zip file na opção ” download type”, Zend, Notepad++,

Gvim
Separei o Gvim por causa de alguns plugins.
Rails, PHP, CSS, CSS Color Preview, javascript, SQL, MySQL Runner e para os que gostam do estilo IDE, tentem o Proj
No caso do Gvim, considere ver o post do wombat modificado.
Também vem vindo aí um post meu sobre vim/gvim… fiquem de olho!

3 – Editores de Imagem

Gimp, Incscape, PickPick (screenshot e color picker).

4 – Escritório / Comunicação

Open-Office, Pidgin, aMsn, Thunderbird e lightning para thunderbird para os calendários e to-do.FoxitReader para abrir pdfs

5 – FTP / SSH

WinScp, FileZilla, Putty

6 – Utilitários

7-zip, FreeFileSync,Font Matcher, WinMerge, InfraRecorder, Wink

7 – Servidores Web

PHP: Xampp,USB Web Server

– UPDATE: pra mim nenhum dos dois servidores para Django funcionaram, se você teve sucesso, poste uma mensagem contando como

Django: IntantDjango, DjangoStack

Estou dividindo o artigo em duas partes e postarei uma por semana, coloquem
suas sugestões nos comentaŕios .

django-openid:

• descrição: suporte a rede OpenID
• site: http://code.google.com/p/django-openid/
• opinião: só se você for usar OpenID para algo…eu particularmente não dou muito para a OpenID por hora mas acredito que tenha futuro.

django-ratings:

• descrição: sistema básico de ratings, eu não usei
• site: http://code.google.com/p/django-ratings/
• opinião: eu não usei, mas o app é bem simples, tem um campo para modelo, manager e models, eu esperava talvez algo como tags, etc. Recentemente eu desenvolvi um sistema customizado de ratings, fechado e bastante especifico. Em breve precisarei de um mais genérico e então farei algo em cima deste app.

django-sphinx

• descrição: permite busca fulltext usando o mecanismo Sphinx, que é melhor que o default do MySQL.
• site: http://code.google.com/p/django-sphinx/
• opinião: muito, muito útil, infelizmente ele precisa do sphinx instalado, o que não ajuda muito pois vários hosts não tem este suporte, entretanto o sphinx é bem mais interessante que outros mecanismos de busca alternativos já que é escrito em C (ou C++) e não em java. Com certeza vou usar em breve.

django-tagging

• descrição: sistema genérico mas eficiente para trabalhar com tags
• site: http://code.google.com/p/django-tagging/
• opção: Muito útil, este com certeza usarei em todos os meus projetos e provavelmente serei um dos contribuidores, pretendo integrar ele a algum sistema de ratings e busca.

django-template-utils

• descrição: Várias adições muito muito boas para o podre sistema de templates do django
• site: http://code.google.com/p/django-template-utils/
• opinião: Necessário. É conhecido que o Django tem um sistema de templates (intencionalmente:) limitado, para questões de segurança e da separação da lógica na parte das views, forms e models. O problema é que eles limitaram demais, e este pacote traz alguma vida adicional a ele. Eu já estou usando.

django-compress

• descrição: compacta seu js e css
• site: http://code.google.com/p/django-compress/
• opinião: faz parte das otimizações de qualquer site otimizar css e js, e ao unificar em um só arquivo melhora no número de requests. o app é realmente muito útil e eu pretendo usá-lo daqui para frente.

django-graphs

• descrição: pelo que li, gráficos bonitinhos para o Django
• site: http://code.google.com/p/django-graphs/
• opção: oferece métodos para gerar gráficos usando cairo e PIL, é bastante interessante mas … eu particulamente estou interessado em algo que gere gráficos onde eu possa interagir, preferencialmente não em flash, já que o suporte a 64 bits ainda é fraco no linux.