Como depurar no Django, da melhor maneira? [fechadas]

Então, comecei a aprender a codificar em Python e mais tarde no Django . Nas primeiras vezes, foi difícil olhar para os rastreamentos e descobrir o que fiz de errado e onde estava o erro de sintaxe. Algum tempo se passou agora e, ao longo do caminho, acho que tenho uma rotina para depurar meu código Django. Como isso foi feito no início da minha experiência em codificação, sentei-me e me perguntei se como estava fazendo isso era ineficaz e poderia ser feito mais rapidamente. Normalmente, consigo encontrar e corrigir os erros no meu código, mas me pergunto se devo fazê-lo mais rapidamente.

Eu normalmente apenas uso as informações de depuração que o Django fornece quando ativadas. Quando as coisas terminam como eu pensava, interrompo muito o fluxo de código com um erro de sintaxe e observo as variáveis ​​nesse ponto do fluxo para descobrir, onde o código faz algo diferente do que eu queria.

Mas isso pode ser melhorado? Existem boas ferramentas ou melhores maneiras de depurar seu código Django?

Existem várias maneiras de fazer isso, mas o mais direto é simplesmente usar o depurador Python . Apenas adicione a seguinte linha em uma função de exibição do Django:

import pdb; pdb.set_trace()

ou

breakpoint()  #from Python3.7

Se você tentar carregar essa página no seu navegador, o navegador travará e você receberá uma solicitação para continuar a depuração do código em execução real.

No entanto, existem outras opções (não as estou recomendando):

* return HttpResponse({variable to inspect})

* print {variable to inspect}

* raise Exception({variable to inspect})

Mas o depurador Python (pdb) é altamente recomendado para todos os tipos de código Python. Se você já está no pdb, também gostaria de dar uma olhada no IPDB que usa o ipython para depuração.

Algumas extensões mais úteis ao pdb são

pdb ++ , sugerido por Antash .

pudb , sugerido por PatDuJour .

Usando o depurador Python no Django , sugerido pelo Seafangs .

Eu realmente gosto do depurador interativo de Werkzeug . É semelhante à página de depuração do Django, exceto que você obtém um shell interativo em todos os níveis do rastreio. Se você usa o django-extensions , obtém um runserver_pluscomando de gerenciamento que inicia o servidor de desenvolvimento e fornece o depurador do Werkzeug em exceções.

Obviamente, você só deve executá-lo localmente, pois ele concede a qualquer pessoa com um navegador o direito de executar código python arbitrário no contexto do servidor.

Um pouco rápido para as tags de modelo:

@register.filter 
def pdb(element):
    import pdb; pdb.set_trace()
    return element

Agora, dentro de um modelo, você pode fazer {{ template_var|pdb }}e entrar em uma sessão pdb (desde que você esteja executando o servidor local de desenvolvimento), onde poderá inspecionar elemento conteúdo do seu coração.

É uma maneira muito agradável de ver o que aconteceu com seu objeto quando ele chega ao modelo.

Existem algumas ferramentas que cooperam bem e podem facilitar sua tarefa de depuração.

O mais importante é a barra de ferramentas de depuração do Django .

Então você precisa de boa logging usando o Python registro de instalação. Você pode enviar a saída de log para um arquivo de log, mas uma opção mais fácil é enviar a saída de log para o firepython . Para usar isso, você precisa usar o navegador Firefox com a extensão firebug . O Firepython inclui um plug-in do firebug que exibirá qualquer log do lado do servidor em uma guia do Firebug.

O Firebug em si também é fundamental para depurar o lado Javascript de qualquer aplicativo que você desenvolver. (Supondo que você tenha algum código JS, é claro).

Também gostei do django-viewtools para depurar visualizações interativamente usando o pdb, mas não o uso muito.

Existem ferramentas mais úteis, como o dozer, para rastrear vazamentos de memória (também existem outras boas sugestões dadas nas respostas aqui no SO para rastreamento de memória).

Eu uso o PyCharm (o mesmo mecanismo pydev do eclipse). Realmente me ajuda a visualmente ser capaz de percorrer meu código e ver o que está acontecendo.

Quase tudo foi mencionado até agora, então apenas acrescentarei que, em vez de pdb.set_trace()usar, pode-se usar ipdb.set_trace (), que usa o iPython e, portanto, é mais poderoso (preenchimento automático e outras vantagens). Isso requer o pacote ipdb, então você só precisapip install ipdb

Eu empurrei django-pdbpara o PyPI . É um aplicativo simples que significa que você não precisa editar seu código-fonte toda vez que quiser entrar no pdb.

A instalação é apenas ...

1. pip install django-pdb
2. Adicione 'django_pdb'ao seuINSTALLED_APPS

Agora você pode executar: manage.py runserver --pdbpara entrar no pdb no início de cada exibição ...

bash: manage.py runserver --pdb
Validating models...

0 errors found
Django version 1.3, using settings 'testproject.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

GET /
function "myview" in testapp/views.py:6
args: ()
kwargs: {}

> /Users/tom/github/django-pdb/testproject/testapp/views.py(7)myview()
-> a = 1
(Pdb)

E execute: manage.py test --pdbpara entrar no pdb em falhas / erros de teste ...

bash: manage.py test testapp --pdb
Creating test database for alias 'default'...
E
======================================================================
>>> test_error (testapp.tests.SimpleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File ".../django-pdb/testproject/testapp/tests.py", line 16, in test_error
    one_plus_one = four
NameError: global name 'four' is not defined
======================================================================

> /Users/tom/github/django-pdb/testproject/testapp/tests.py(16)test_error()
-> one_plus_one = four
(Pdb)

O projeto está hospedado no GitHub , é claro que contribuições são bem-vindas.

A maneira mais fácil de depurar o python - especialmente para programadores acostumados ao Visual Studio - é usar o PTVS (Python Tools for Visual Studio). Os passos são simples:

1. Faça o download e instale-o em http://pytools.codeplex.com/
2. Defina pontos de interrupção e pressione F5.
3. Seu ponto de interrupção é atingido, você pode visualizar / alterar as variáveis ​​tão facilmente quanto depurar programas em C # / C ++.
4. Isso é tudo :)

Se você deseja depurar o Django usando PTVS, faça o seguinte:

1. Em Configurações do projeto - guia Geral, defina "Arquivo de inicialização" como "manage.py", o ponto de entrada do programa Django.
2. Nas configurações do projeto - guia Debug, defina "Argumentos de script" como "runserver --noreload". O ponto principal é o "--noreload" aqui. Se você não definir, seus pontos de interrupção não serão atingidos.
3. Aproveite.

Eu uso o pyDev com o Eclipse muito bom, defina pontos de interrupção, entre no código, visualize valores em quaisquer objetos e variáveis, experimente.

Eu uso o PyCharm e aguento o tempo todo. Custou-me um pouco, mas tenho que dizer que a vantagem de obter disso não tem preço. Tentei depurar no console e concedo muito crédito às pessoas que podem fazer isso, mas para mim é possível depurar visualmente meus aplicativos.

Eu tenho que dizer, porém, PyCharm muita memória. Mas, novamente, nada de bom é gratuito na vida. Eles vieram apenas com a versão mais recente 3. Também funciona muito bem com Django, Flask e Google AppEngine. Então, apesar de tudo, eu diria que é uma ótima ferramenta útil para qualquer desenvolvedor.

Se você ainda não o estiver usando, recomendo a versão de teste por 30 dias para conhecer o poder do PyCharm. Tenho certeza de que existem outras ferramentas também disponíveis, como o Aptana. Mas acho que também gosto da aparência do PyCharm. Eu me sinto muito confortável depurando meus aplicativos lá.

Às vezes, quando eu quero explorar um método específico e convocar pdb é muito complicado, eu acrescentaria:

import IPython; IPython.embed()

IPython.embed() inicia um shell IPython que tem acesso às variáveis ​​locais a partir do ponto em que você o chama.

Na minha perspectiva, poderíamos dividir tarefas comuns de depuração de código em três padrões de uso distintos:

1. Algo levantou uma exceção : o depurador Werkzeug do runserver_plus para o resgate. A capacidade de executar código personalizado em todos os níveis de rastreio é excelente. E se você estiver completamente paralisado, poderá criar um Gist para compartilhar com apenas um clique.
2. A página é renderizada, mas o resultado está errado : novamente, Werkzeug é ótimo. Para criar um ponto de interrupção no código, basta digitar assert Falseo local em que deseja parar.
3. O código funciona errado , mas a rápida visualização não ajuda. Provavelmente, um problema algorítmico. Suspiro. Então eu geralmente o fogo até uma consola debugger PuDB : import pudb; pudb.set_trace(). A principal vantagem sobre o [i] pdb é que o PuDB (enquanto você está nos anos 80) facilita muito a configuração de expressões personalizadas de relógio. E depurar um monte de loops aninhados é muito mais simples com uma GUI.

Ah, sim, os problemas dos modelos. O problema mais comum (para mim e meus colegas) é um contexto errado: ou você não tem uma variável ou sua variável não tem algum atributo. Se você estiver usando barra de ferramentas de depuração , basta inspecionar o contexto na seção "Modelos" ou, se não for suficiente, defina uma quebra no código de suas visualizações logo após o preenchimento do contexto.

Assim vai.

Eu recomendo o epdb (Extended Python Debugger).

https://bitbucket.org/dugan/epdb

Uma coisa que eu amo no epdb para depurar o Django ou outros servidores Web Python é o comando epdb.serve (). Isso define um rastreamento e serve isso em uma porta local à qual você pode se conectar. Caso de uso típico:

Eu tenho uma visão de que quero passar passo a passo. Vou inserir o seguinte no ponto em que quero definir o rastreamento.

import epdb; epdb.serve()

Depois que esse código é executado, abro um interpretador Python e conecto à instância de veiculação. Posso analisar todos os valores e percorrer o código usando os comandos pdb padrão, como n, s, etc.

In [2]: import epdb; epdb.connect()
(Epdb) request
<WSGIRequest
path:/foo,
GET:<QueryDict: {}>, 
POST:<QuestDict: {}>,
...
>
(Epdb) request.session.session_key
'i31kq7lljj3up5v7hbw9cff0rga2vlq5'
(Epdb) list
 85         raise some_error.CustomError()
 86 
 87     # Example login view
 88     def login(request, username, password):
 89         import epdb; epdb.serve()
 90  ->     return my_login_method(username, password)
 91
 92     # Example view to show session key
 93     def get_session_key(request):
 94         return request.session.session_key
 95

E muito mais que você pode aprender sobre como digitar a ajuda do epdb a qualquer momento.

Se você deseja atender ou conectar-se a várias instâncias do epdb ao mesmo tempo, pode especificar a porta para escutar (o padrão é 8080). Ou seja,

import epdb; epdb.serve(4242)

>> import epdb; epdb.connect(host='192.168.3.2', port=4242)

o padrão do host é 'localhost' se não for especificado. Eu joguei aqui para demonstrar como você pode usar isso para depurar algo diferente de uma instância local, como um servidor de desenvolvimento na sua LAN local. Obviamente, se você fizer isso, tenha cuidado para que o rastreio definido nunca chegue ao seu servidor de produção!

Como uma observação rápida, você ainda pode fazer a mesma coisa que a resposta aceita com epdb ( import epdb; epdb.set_trace()), mas eu queria destacar a funcionalidade de veiculação, já que a achei muito útil.

Acabei de encontrar o wdb ( http://www.rkblog.rk.edu.pl/w/p/debugging-python-code-browser-wdb-debugger/?goback=%2Egde_25827_member_255996401 ). Ele tem uma interface de usuário / GUI bastante agradável com todos os sinos e assobios. O autor diz isso sobre o wdb -

"Existem IDEs, como o PyCharm, que possuem seus próprios depuradores. Eles oferecem um conjunto de recursos semelhante ou igual ... No entanto, para usá-los, é necessário usar esses IDEs específicos (e alguns deles não são gratuitos ou podem não estar disponíveis para todos). plataformas). Escolha a ferramenta certa para suas necessidades. "

Pensei em passar adiante.

Também um artigo muito útil sobre depuradores python: https://zapier.com/engineering/debugging-python-boss/

Finalmente , se você quiser ver uma boa impressão gráfica da sua pilha de chamadas no Django, confira: https://github.com/joerick/pyinstrument . Basta adicionar pyinstrument.middleware.ProfilerMiddleware a MIDDLEWARE_CLASSES e, em seguida, adicionar? Profile ao final do URL da solicitação para ativar o criador de perfil.

Também pode executar pyinstrument a partir da linha de comando ou importando como um módulo.

Adicione import pdb; pdb.set_trace()ou breakpoint() (formulário python3.7) na linha correspondente no código Python e execute-o. A execução será interrompida com um shell interativo. No shell, você pode executar o código Python (ou seja, variáveis ​​de impressão) ou usar comandos como:

• c continuar execução
• n passo para a próxima linha dentro da mesma função
• s vá para a próxima linha nesta função ou uma função chamada
• q saia do depurador / execução

Consulte também: https://poweruser.blog/setting-a-breakpoint-in-python-438e23fe6b28

Uma de suas melhores opções para depurar o código do Django é via wdb: https://github.com/Kozea/wdb

O wdb trabalha com python 2 (2.6, 2.7), python 3 (3.2, 3.3, 3.4, 3.5) e pypy. Melhor ainda, é possível depurar um programa python 2 com um servidor wdb executando no python 3 e vice-versa ou depurar um programa executando em um computador com um servidor de depuração executando em outro computador dentro de uma página da web em um terceiro computador! Ainda melhor, agora é possível pausar um processo / thread python atualmente em execução usando injeção de código da interface da web. (Isso requer o gdb e o ptrace ativados) Em outras palavras, é uma versão muito aprimorada do pdb diretamente no seu navegador com recursos agradáveis.

Instale e execute o servidor e, em seu código, adicione:

import wdb
wdb.set_trace()

Segundo o autor, as principais diferenças em relação a pdbsão:

Para quem não conhece o projeto, o wdb é um depurador python como o pdb, mas com um front-end da web sofisticado e muitos recursos adicionais, como:

• Destaque da sintaxe de origem
• Pontos de interrupção visuais
• Conclusão interativa de código usando jedi
• Pontos de interrupção persistentes
• Inspeção profunda de objetos usando o mouse Multithreading / Multiprocessing support
• Depuração remota
• Assistir expressões
• Na edição do código do depurador
• Integração popular de servidores da Web para quebrar com erros
• Na exceção de quebra durante o rastreamento (não post-mortem), ao contrário do depurador werkzeug, por exemplo
• Interrupção nos programas atualmente em execução por injeção de código (em sistemas suportados)

Possui uma ótima interface de usuário baseada em navegador. Uma alegria de usar! :)

Eu uso o PyCharm e diferentes ferramentas de depuração. Também tenha um bom conjunto de artigos sobre a configuração fácil dessas coisas para iniciantes. Você pode começar aqui. Ele fala sobre depuração de PDB e GUI em geral com projetos Django. Espero que alguém se beneficie deles.

Se estiver usando o Aptana para desenvolvimento de django, assista a este: http://www.youtube.com/watch?v=qQh-UQFltJQ

Caso contrário, considere usá-lo.

A maioria das opções já é mencionada. Para imprimir o contexto do modelo, criei uma biblioteca simples para isso. Consulte https://github.com/edoburu/django-debugtools

Você pode usá-lo para imprimir o contexto do modelo sem nenhuma {% load %}construção:

{% print var %}   prints variable
{% print %}       prints all

Ele usa um formato de impressão personalizado para exibir as variáveis ​​em uma <pre>tag.

Acho que o Visual Studio Code é incrível para depurar aplicativos Django. Os parâmetros padrão do python launch.json são executados python manage.pycom o depurador conectado, para que você possa definir pontos de interrupção e percorrer seu código como desejar.

Para aqueles que podem adicionar acidentalmente pdb em confirmações ao vivo, posso sugerir esta extensão da resposta #Koobz:

@register.filter 
def pdb(element):
    from django.conf import settings
    if settings.DEBUG:    
        import pdb
        pdb.set_trace()
    return element

De minha própria experiência, há duas maneiras:

1. use ipdb , que é um depurador aprimorado que gosta de pdb.

   import ipdb;ipdb.set_trace()ou breakpoint() (do python3.7)

2. use shell django, basta usar o comando abaixo. Isso é muito útil quando você está desenvolvendo uma nova exibição.

   python manage.py shell

Eu sugiro usar PDB.

import pdb
pdb.set_trace()

Você pode inspecionar todos os valores das variáveis, entrar na função e muito mais. https://docs.python.org/2/library/pdb.html

Para verificar todo o tipo de solicitação, resposta e hits do database.i, estou usando o django-debug-toolbar https://github.com/django-debug-toolbar/django-debug-toolbar

Como mencionado em outros posts aqui - definir pontos de interrupção no seu código e percorrer o código para ver se ele se comporta como o esperado, é uma ótima maneira de aprender algo como o Django até que você tenha uma boa noção de como tudo se comporta - e qual é o seu código está fazendo.

Para fazer isso, eu recomendaria o uso do WingIde. Assim como outros IDEs mencionados, agradáveis ​​e fáceis de usar, bom layout e também fáceis de definir pontos de interrupção, avaliam / modificam a pilha etc. Perfeito para visualizar o que seu código está fazendo quando você o percorre. Eu sou um grande fã disso.

Também uso o PyCharm - ele tem uma excelente análise de código estático e às vezes pode ajudar a detectar problemas antes que você perceba que eles estão lá.

Como já mencionado, o django-debug-toolbar é essencial - https://github.com/django-debug-toolbar/django-debug-toolbar

E embora não seja explicitamente uma ferramenta de depuração ou análise - um dos meus favoritos é o SQL Printing Middleware disponível no Django Snippets em https://djangosnippets.org/snippets/290/

Isso exibirá as consultas SQL que sua exibição gerou. Isso lhe dará uma boa noção do que o ORM está fazendo e se suas consultas são eficientes ou você precisa refazer seu código (ou adicionar cache).

Acho inestimável manter um olho no desempenho da consulta ao desenvolver e depurar meu aplicativo.

Apenas mais uma dica - modifiquei-a levemente para uso próprio, para mostrar apenas o resumo e não a instrução SQL ... Portanto, sempre a uso durante o desenvolvimento e o teste. Eu também adicionei que, se o len (connection.queries) for maior que um limite predefinido, ele exibirá um aviso extra.

Então, se detectar algo ruim (do ponto de vista do desempenho ou do número de consultas), eu volto à exibição completa das instruções SQL para ver exatamente o que está acontecendo. Muito útil quando você está trabalhando em um grande projeto Django com vários desenvolvedores.

use pdbou ipdb. A diferença entre esses dois é o ipdb suporta auto complete.

para pdb

import pdb
pdb.set_trace()

para ipdb

import ipdb
ipdb.set_trace()

Para executar a nova ntecla de pressionamento de linha , para continuar pressionando a ctecla. verifique mais opções usandohelp(pdb)

Uma sugestão adicional.

Você pode alavancar nosetests e pdb juntos, injetando pdb.set_trace()manualmente suas visualizações. A vantagem é que você pode observar as condições de erro quando elas são iniciadas, potencialmente no código de terceiros.

Aqui está um erro para mim hoje.

TypeError at /db/hcm91dmo/catalog/records/

render_option() argument after * must be a sequence, not int

....


Error during template rendering

In template /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/crispy_forms/templates/bootstrap3/field.html, error at line 28
render_option() argument after * must be a sequence, not int
18  
19          {% if field|is_checkboxselectmultiple %}
20              {% include 'bootstrap3/layout/checkboxselectmultiple.html' %}
21          {% endif %}
22  
23          {% if field|is_radioselect %}
24              {% include 'bootstrap3/layout/radioselect.html' %}
25          {% endif %}
26  
27          {% if not field|is_checkboxselectmultiple and not field|is_radioselect %}
28  

      {% if field|is_checkbox and form_show_labels %}

Agora, eu sei que isso significa que enganei o construtor do formulário e até tenho uma boa idéia de qual campo é um problema. Mas, posso usar o pdb para ver o que os formulários crocantes estão reclamando em um modelo ?

Sim eu posso. Usando o --pdb opção nosetests:

tests$ nosetests test_urls_catalog.py --pdb

Assim que eu clico em qualquer exceção (incluindo as tratadas normalmente), o pdb para onde isso acontece e posso olhar em volta.

  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/forms/forms.py", line 537, in __str__
    return self.as_widget()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/forms/forms.py", line 593, in as_widget
    return force_text(widget.render(name, self.value(), attrs=attrs))
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/forms/widgets.py", line 513, in render
    options = self.render_options(choices, [value])
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/forms/widgets.py", line 543, in render_options
    output.append(self.render_option(selected_choices, *option))
TypeError: render_option() argument after * must be a sequence, not int
INFO lib.capture_middleware log write_to_index(http://localhost:8082/db/hcm91dmo/catalog/records.html)
INFO lib.capture_middleware log write_to_index:end
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/forms/widgets.py(543)render_options()
-> output.append(self.render_option(selected_choices, *option))
(Pdb) import pprint
(Pdb) pprint.PrettyPrinter(indent=4).pprint(self)
<django.forms.widgets.Select object at 0x115fe7d10>
(Pdb) pprint.PrettyPrinter(indent=4).pprint(vars(self))
{   'attrs': {   'class': 'select form-control'},
    'choices': [[('_', 'any type'), (7, (7, 'type 7', 'RECTYPE_TABLE'))]],
    'is_required': False}
(Pdb)         

Agora, está claro que meu argumento de escolhas para o construtor de campo crocante era como uma lista dentro de uma lista, em vez de uma lista / tupla de tuplas.

 'choices': [[('_', 'any type'), (7, (7, 'type 7', 'RECTYPE_TABLE'))]]

O mais interessante é que esse pdb está ocorrendo no código do crispy, não no meu, e eu não precisava inseri-lo manualmente.

Durante o desenvolvimento, adicionar uma rápida

assert False, value

pode ajudar a diagnosticar problemas nas visualizações ou em qualquer outro lugar, sem a necessidade de usar um depurador.