Instalá-lo é muito fácil, se você possui easy_install é só executar:

sudo easy_install winpdb

Se você não tem easy_install, mas tem apt-get:

sudo apt-get install winpdb

Se você não tem nada disso ainda dá pra baixar pelo site[3] e funciona no Windows também, mas eu não testei.

Usarei como exemplo o código criado pelo post anterior, é um projeto bem simples com apenas uma view para atestar o poder do debug.

Lembra da nossa view, ela é simples assim:

def hello(request):
    a = 2
    b = 3
    c = [1,2,3]
    c.pop()
    d = soma(3,4)
    response = HttpResponse("Hello World")
    return response

Como o winpdb possui a funcionalidade de adicionar breakpoints eu tirei aquele código de debug do pdb senão eles conflitariam entre si.

Abra o winpdb:

A interface dele é bem simples, ficará mais clara quando estivermos executando alguma coisa.

Vá até File->Launch e na janela aberta escolha o manage.py do projeto que vamos depurar, por fim adicione runserver --noreload no comando e então clique em OK para iniciar o servidor.

O seu winpdb deve ficar parecido com a imagem abaixo, além de um terminal que será aberto pelo próprio winpdb.

Antes de continuar qualquer coisa, vá até File->Open Source e na janela aberta escolha o arquivo views.py, adicione um breakpoint na linha a = 2 clicando à direita do número da linha. Tente acessar a URL que executa a view hello e volte ao winpdb, você verá algo como abaixo (a diferença é que eu já andei duas linhas no código):

Essa imagem é bem interessante pois mostra valores das variáveis, um console escondido abaixo do código, o arquivo em que o debugger se encontra, controles de avanço do debug, etc.

Avance com Control->Next até a chamada de soma e entre com Control->Step Into, avance duas linhas e você ficará assim:

As variáveis do escopo local mudaram, o debugger continua no views.py mas agora dentro da função soma, dê Control->Return para ir até antes da função retornar pro escopo de hello.

Com Control->Next vá até antes da linha que executa return response e vamos brincar um pouco com o console que se encontra abaixo do código-fonte:

Como você pode ver na imagem, o comando v (de eval) seguido de uma expressão retorna o valor da expressão, já o comando x (de exec) seguido de uma expressão executa a expressão informada.

Vamos fazer igual ao post anterior e verificar as propriedades de response:

Na imagem acima, executamos um dir na variável response, exibimos seu content com v, alteramos o content com x e por fim com Control->Go visualizamos o resultado no navegador:

Para saber de mais funcionalidades que o winpdb pode te oferecer dê uma olhada no tutorial[4] (bem completo por sinal) que se encontra na própria wiki[5] deles.

[1] – http://blog.danilocabello.com/arquivo/debugando-no-django/
[2] – http://docs.python.org/library/pdb.html
[3] – http://winpdb.org/
[4] – http://winpdb.org/cgi-bin/moin.cgi/WinpdbTutorial
[5] – http://winpdb.org/cgi-bin/moin.cgi/FrontPage

Primeiramente, debugar um projeto em Python[2] e debugar um projeto em Django não tem muita diferença, a coisa toda é muito parecida, você só precisa do pontapé inicial para se virar dali pra frente.

Para aprender como utilizar o pdb[3] (vulgo Python Debugger) crie um novo projeto chamado djdebug, logo em seguida crie um arquivo vazio chamado views.py na própria raiz do projeto, ficando com a seguinte estrutura de arquivos:

djdebug
  - __init__.py
  - manage.py
  - settings.py
  - urls.py
  - views.py

No arquivo views.py cole o seguinte código:

from django.shortcuts import HttpResponse

def soma(a,b):
    arg1 = a
    arg2 = b
    soma = arg1 + arg2
    return soma

def hello(request):
    a = 2
    b = 3
    c = [1,2,3]
    c.pop()
    d = soma(3,4)
    response = HttpResponse("Hello World")
    return response

Como podemos ver o arquivo contém uma função soma, que não faz nada de muito complexo e uma função hello que retorna uma response com o conteúdo "Hello World".

No arquivo urls.py importe a view hello e adicione uma URL para podemos acessá-la:

from views import hello

urlpatterns = patterns('',
    ...
    (r'^hello', hello),
)

Execute o servidor de testes, navegue até http://localhost:8000/hello e verifique que está tudo funcionando:

./manage runserver

Suponha que há um bug em alguma parte da view hello e então adicione o código para possibilitar o debug:

def hello(request):
    a = 2
    import pdb
    pdb.set_trace()
    ...

Apenas para esclarecer, o import pdb importa o Python debugger, já o pdb.set_trace() serve pra colocar um breakpoint no código, há maneiras de se colocar um breakpoint no código sem alterá-lo através do próprio pdb[3].

Execute o servidor de testes mas desta vez adicione o parâmetro necessário para evitar recarregamento automático do código-fonte:

./manage runserver --noreload

Abra novamente a view hello no seu navegador, ela ficará parada e no terminal que você iniciou o servidor o pdb[3] estará parado esperando por comandos:

> /home/.../djdebug/views.py(13)hello()
-> b = 3
(Pdb)

Vamos começar, temos um comando interessante que é o l (de list, lista o código na região do debugger) que lista onde se encontra o debugger:

(Pdb) l
  8
  9  	def hello(request):
 10  	    a = 2
 11  	    import pdb
 12  	    pdb.set_trace()
 13      ->  b = 3
 14  	    c = [1,2,3]
 15  	    c.pop()
 16  	    d = soma(3,4)
 17  	    response = HttpResponse("Hello World")
 18  	    return response

É importante notar que o debugger se encontra no exato momento antes de executar a linha apontada pela seta, isto é, se executarmos p (de print, imprime a expressão passada como argumento) para inspecionarmos a variável b, ela não estará definida:

(Pdb) p a
2
(Pdb) p b
*** NameError: NameError("name 'b' is not defined",)

Vamos para próxima linha com n (de next, segue para a próxima linha):

(Pdb) n
> /home/.../djdebug/views.py(14)hello()
-> c = [1,2,3]
(Pdb) p b
3

Agora sim b já possui valor, vamos avançar até a chamada da função somar:

(Pdb) n
> /home/.../djdebug/views.py(15)hello()
-> c.pop()
(Pdb) <enter>
> /home/.../djdebug/views.py(16)hello()
-> d = soma(3,4)

A partir do primeiro n, enter executará n novamente. Como nós não sabemos se o problema da view hello é a função somar, vamos entrar na função somar com s (de step into, entra na função, ou seja, passo a dentro) e verificar se está tudo certo:

(Pdb) s
--Call--
> /home/.../djdebug/views.py(3)soma()
-> def soma(a,b):
(Pdb) l
  1  	  from django.shortcuts import HttpResponse
  2
  3     -> def soma(a,b):
  4  	      arg1 = a
  5  	      arg2 = b
  6  	      soma = arg1 + arg2
  7  	      return soma
  8
  9  	  def hello(request):
 10  	      a = 2
 11  	      import pdb

Como podemos ver o debugger se encontra na entrada da função soma, damos uma “olhada por cima” e saímos da função com up (de up, sobe uma chamada na pilha):

> /home/.../djdebug/views.py(4)soma()
-> arg1 = a
(Pdb) n
> /home/.../djdebug/views.py(5)soma()
-> arg2 = b
(Pdb) n
> /home/.../djdebug/views.py(6)soma()
-> soma = arg1 + arg2
(Pdb) u
> /home/.../djdebug/views.py(16)hello()
-> d = soma(3,4)

Como podemos ver, voltamos a view hello, vamos avançar até antes de retornar a resposta da requisição e atestar umas coisinhas:

(Pdb) n
> /home/.../djdebug/views.py(17)hello()
-> response = HttpResponse("Hello World")
(Pdb) n
> /home/.../djdebug/views.py(18)hello()
-> return response
(Pdb) dir(response)
['__class__', '__contains__', '__delattr__', '__delitem__', '__dict__', '__doc__', '__format__', '__getattribute__', '__getitem__', '__hash__', '__init__', '__iter__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__setitem__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', '_charset', '_container', '_convert_to_ascii', '_get_content', '_headers', '_is_string', '_set_content', 'close', 'content', 'cookies', 'delete_cookie', 'flush', 'get', 'has_header', 'items', 'next', 'set_cookie', 'status_code', 'tell', 'write']
(Pdb) response.content
'Hello World'
(Pdb) response.content = 'Django debugado'
(Pdb) c

Como podemos verificar, o pdb[3] fornece um shell do Python[2] você pode executar dir, verificar valores de variáveis e até mudar conteúdo de variáveis (poder e perigo andando juntos), por fim executamos c (de continue, para continuar a execução), veja o resultado no seu navegador, a mensagem "Hello World" foi trocada por "Django debugado".

Recomendo a leitura do paper “Debugging in Python”[4] para mais alguns detalhes do pdb[3]. É muito interessante saber “brincar” com o shell do Python e do Django, com essas ferramentas fica mais fácil rastrear o chato do bug.

[1] - http://www.djangoproject.com/
[2] – http://www.python.org/
[3] – http://docs.python.org/library/pdb.html
[4] – http://www.ferg.org/papers/debugging_in_python.html

A aplicação é muito completa, possui testes e exige o mínimo de conhecimento em Django que é saber criar templates. Ao baixar a aplicação eu pensei que iria ter que adaptar um monte de coisa para se encaixar na minha aplicação, que nada, a aplicação está no limite da plugabilidade que o Django investe.

Give a try.

[1] – http://docs.djangoproject.com/en/dev/topics/auth/#topics-auth
[2] – http://bitbucket.org/ubernostrum/django-registration/

Esqueça às dores de cabeça, na versão 1.0 do Django foi lançanda a Form Wizard, ferramenta que tem como objetivo facilitar a criação de formulários com vários passos.

Vamos a um exemplo funcional com FormWizard, para isso eu criei um projeto chamado “templo” e uma aplicação chamada “mago”, dentro da minha aplicação eu criei o arquivo forms.py com o seguinte código:

from django import forms
from django.contrib.formtools.wizard import FormWizard
from django.shortcuts import render_to_response
 
class Pessoa(forms.Form):
    nome = forms.CharField(max_length=50)
    email = forms.EmailField()
 
class Mensagem(forms.Form):
    assunto = forms.CharField(max_length=30)
    mensagem = forms.CharField(widget=forms.widgets.Textarea)
 
class Formumago(FormWizard):
    def done(self, request, form_list):
        form_data = {}
        for form in form_list:
            for field, value in form.cleaned_data.iteritems():
                form_data[field] = value
        return render_to_response('agradecimento.html', {
            'form_data': form_data,
        })

A primeira classe Pessoa é um formulário normal como todos os outros em Django com o dados da pessoa que está enviando a mensagem, a segunda classe Mensagem é outro formulário normal com os dados da mensagem, já o Formumago é um formulário especial que herda de FormWizard e tem uma função implementada done que possui o paramêtro form_list além dos comuns self e request e que é chamada após o usuário validar todos os passos.

Depois explicaremos melhor a função done vamos agora para o urls.py para fazer nossa aplicação exemplo funcionar:

from django.conf.urls.defaults import *
from templo.mago.forms import Pessoa, Mensagem, Formumago
 
urlpatterns = patterns('',
    (r'^contato/$', Formumago([Pessoa, Mensagem])),
)

No arquivo urls.py acontece a magia onde criamos um formulário com dois passos o primeiro é o formulário de Pessoa e o segundo de Mensagem. Por padrão o FormWizard procura pelo template em “forms/wizard.html” mas você pode usar outro caminho definindo uma função get_template em Formumago como explicado na documentação.

E o arquivo “forms/wizard.html” que usaremos como template:

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

<form action="." method="post">
<table border="0">
    {% ifequal step 1 %}
        <h1>Primeiro passo</h1>
        <h2>Seus dados pessoais</h2>
    {% endifequal %}
 
    {% ifequal step 2 %}
        <h1>Segundo e último passo</h1>
        <h2>Dados da mensagem</h2>
    {% endifequal %}
    <input name="{{ step_field }}" type="hidden" value="{{ step0 }}" />
    {{ previous_fields|safe }}
    {{ form }}</table>
<input type="submit" value="Submit" />
</form>

Como explicado na documentação o input na linha 12 e a variável previous_fields na linha 13 são necessárias para o funcionamento correto do FormWizard.

Temos também o template “agradecimento.html” mencionado no método done da classe Formumago e que exibe os dados que o usuário digitou:

<h1>Obrigado pelo contato</h1>
<h2>Sua mensagem foi enviada com os seguintes dados</h2>
<h3>Dados pessoais</h3>
<ul>
	<li>Nome: {{ form_data.nome }}</li>
	<li>Email: {{ form_data.email }}</li>
</ul>
<h3>Dados da mensagem</h3>
<ul>
	<li>Assunto: {{ form_data.assunto }}</li>
	<li>Mensagem: {{ form_data.mensagem }}</li>
</ul>

Ao executar o servidor do Django e acessarmos a página de contato, obtemos o resultado:

O primeiro passo é exibido corretamente e se preencho algo errado a validação reclama prontamente.

Ao digitar os dados corretamente o segundo passo é exibido:

Novamente a validação do formulário funciona normalmente.

Por fim o método done de Formumago pega os valores limpos e passa ao template de agradecimento apenas com o intuito de mostrar que tipo de dado vem em form_list:

def done(self, request, form_list):
        form_data = {}
        for form in form_list:
            for field, value in form.cleaned_data.iteritems():
                form_data[field] = value
        return render_to_response('agradecimento.html', {
            'form_data': form_data,
        })

O conteúdo de form_list é uma lista de objetos que herdam de forms, algo do tipo [form1, form2] e cada formulário possui seus próprios métodos, save, clean, entre outros, no caso de done a informação válida digitada no formulário é iterada formando uma novo dicionário form_data com todos os campos preenchidos à serem exibidos na página de agradecimento.

Com isso fica fácil implementar formulários com múltiplos passos apenas aproveitando os formulários que já funcionam no projeto.

Baixe o projeto exemplo.

• Documentação Form Wizard
• Inspiração e Fonte